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Abstract 


The  Recognized  Air  Picture  (RAP)  is  an  important  element  of  Air  Force  operations 
which  can  be  associated  with  the  Common  Operational  Picture  (COP).  With  the 
Common  Tactical  Picture  (CTP),  they  provide  Air  Force  commanders  with  the 
necessary  situation  awareness  (SA),  indicating,  in  real  time,  the  status  of  deployed 
friendly  and  enemy  assets.  In  the  13dw  project,  DRDC  Valcartier  investigated 
concepts  that  could  improve  the  implementation  of  a  dynamic  RAP  and  its  exploitation 
for  the  management  of  Canadian  Air  Force  resources  in  real-time  operations.  Such  an 
implementation  requires  the  definition  of  a  reference  scenario  and  the  development  of 
a  simulation  tool.  On  the  one  hand,  an  analysis  of  five  existing  scenarios  led  to  the 
choice  of  the  North  Atlantis  scenario,  on  top  of  which  depicting  a  Combat  Search  and 
Rescue  (CSAR)  mission  vignette  was  developed.  On  the  other  hand,  the  analysis  of 
some  existing  simulation  tools  (two  commercial  tools  and  two  R&D  tools  designed  at 
DRDC  Valcartier)  led  to  recommendations  for  the  development  of  a  dynamic  RAP 
tool. 

Resume 


La  Situation  aerienne  generate  (SAG)  est  un  element  important  des  operations  des 
forces  aeriennes  qui  peut  etre  associe  a  Tlmage  Operationnelle  Commune  (IOC). 
Utilise  conjointement  avec  Tlmage  Tactique  Commune  (ITC)  Tensemble  foumit  aux 
commandants  des  forces  aeriennes  Teveil  situationnel  necessaire  au  suivi,  en  temps 
reel,  de  l’etat  du  deployment  des  forces  amies  et  ennemies.  Dans  le  cadre  du  projet 
13dw,  RDDC  Valcartier  a  etudie  differents  concepts  qui  pourraient  ameliorer 
T  implantation  d’une  SAG  dynamique  ainsi  que  son  exploitation  pour  la  gestion  en 
temps  reel  des  ressources  des  Forces  aeriennes  canadiennes.  Cette  implantation 
necessite  la  definition  d’un  scenario  de  reference  ainsi  que  le  developpement  d’outils 
de  simulation.  D’une  part,  une  analyse  de  cinq  scenarios  existants  a  conduit  a 
selectionner  le  scenario  North  Atlantis  sur  lequel  a  ete  developpee  une  vignette 
decrivant  une  mission  de  Recherche  Et  Sauvetage  au  Combat  (RESC).  D’autre  part, 

T analyse  de  plusieurs  outils  de  simulation  (dont  deux  commerciaux  et  deux  congus  a 
RDDC  Valcartier)  a  permis  de  recommander  la  marche  a  suivre  pour  le 
developpement  d’un  outil  de  compilation  et  d’ exploitation  d’une  SAG  dynamique. 
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Executive  summary 


In  the  Canadian  Air  Force,  commanders  rely  on  two  systems  to  provide  them  with  the 
necessary  situational  awareness  when  conducting  dynamic  missions.  The  Common 
Tactical  Picture  (CTP)  provides  the  tactical  information  required  for  the  control  of 
combat  and  combat  support  assets.  It  requires  real-time  or  near-real  time  access  to 
feeds  from  land,  surface  and  airborne  sensors.  The  Common  Operational  Picture 
(COP)  provides  all  the  necessary  information  for  decision-making  at  the  strategic  and 
operational  levels.  The  COP  could  be  considered  as  a  simplified  view  of  the  CTP, 
including  a  digitized  representation  of  assets  and  tracks  of  interest. 

The  Recognized  Air  Picture  (RAP)  is  associated  with  the  Canadian  Air  Force  COP.  It 
is  considered  as  a  means  for  commanders  to  assess  and  understand  a  running  situation 
and  to  monitor  it  as  it  develops. 

DRDC  conducted  an  R&D  study  to  support  the  Canadian  Air  Force  in  improving  the 
implementation  of  the  dynamic  RAP  and  its  exploitation  for  the  management  of 
resources  and  assets  in  real-time  operations.  It  was  decided  that  in  order  to  support  this 
R&D  effort,  a  reference  scenario  and  simulation  environment  should  be  selected. 

Five  reference  scenarios  were  analyzed: 

•  CF  Security  Support  to  the  Winter  Olympics  2010; 

•  Atlantic  Littoral  ISR  Experiment  (ALIX); 

•  Force  Planning  Scenario  #4:  Surveillance/Control  of  Canadian  Territory  and 
Approaches; 

•  Force  Planning  Scenario  #10:  Defence  of  North  America; 

•  Joint  Warrior  Interoperability  Demonstration  (JWID); 

•  Exercise  Final  Lance:  Atlantis. 

The  comparison  of  these  was  based  on  five  aspects:  (1)  the  richness  of  information,  (2) 
the  tactical  realism  from  a  conduct  of  operations  point  of  view,  (3)  courses  open  to 
friendly  and  enemy  assets,  (4)  the  utility  of  the  scenario  for  the  compilation  and 
exploitation  of  the  RAP,  and  (5)  the  level  of  detail  and  the  facility  to  develop 
vignettes.  The  Final  Lance  Atlantis  scenario  was  considered  the  best  and  was  selected 
for  this  study. 

A  Combat  Search  and  Rescue  (CSAR)  vignette  was  then  defined.  The  CSAR  domain 
was  chosen  since  it  presents  many  challenges  to  the  mission  planner  due  to  the  highly 
dynamic  and  unpredictable  nature  of  such  operations. 
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Once  the  vignette  was  defined,  it  was  necessary  to  identify  the  most  suitable 
simulation  tool  for  running  the  vignette  and  supporting  the  RAP  R&D  work. 


Two  commercial  tools  were  analyzed:  the  Ship  Air  Defense  Model  (SADM) 
developed  by  British  Aerospace  (BAE)  and  the  Integrated  Anti- Ship  Missile  Defence 
Analysis  and  Simulation  Software  designed  by  Tactical  Technologies  Inc.  (TTI).  Two 
other  R&D  tools  were  also  analyzed:  the  CASEATTI  tool  developed  by  the  Decision 
Support  Systems  team  at  DRDC  Valcartier,  and  the  KARMA  environment,  also 
developed  at  DRDC  Valcartier. 

The  analysis  of  these  tools  was  based  on  two  types  of  criteria:  the  first  based  purely  on 
software  engineering,  and  the  second  more  oriented  toward  application  needs  in  terms 
of  RAP  functionalities  to  conduct  CSAR  simulations.  The  output  of  this  comparative 
analysis  was  in  the  form  of  recommendations  for  the  selection  and  further 
development  of  a  customized  simulation  tool. 


Allouche,  M.,  Belanger,  M.,  Maupin,  P..  2007.  RAP  simulation  environment 
characteristics.  DRDC  Valcartier  TM  2006-702  DRDC  Valcartier. 
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Sommaire 


Les  commandants  des  forces  canadiennes  comptent  sur  deux  systemes  pour  foumir 
l’eveil  situationnel  necessaire  lors  de  conduite  de  missions  dynamiques.  L’image 
tactique  commune  foumit  les  informations  tactiques  necessaires  pour  le  controle  des 
ressources  de  combat  et  de  support.  Ceci  requiere  un  acces  temps  reel  ou  quasi  temps 
reel  aux  donnees  provenant  de  sources  terrestres,  de  surface  et  aeriennes.  L’image 
operationnelle  commune  fournit  toutes  les  informations  necessaires  pour  la  prise  de 
decision  aux  niveaux  operationnel  et  strategique.  Elle  peut  etre  consideree  comme  une 
image  simplifiee  de  la  l’image  tactique  commune  incluant  une  representation 
digitalisee  des  ressources  et  des  tracks  d’interet. 

La  situation  aerienne  generale  est  associee  a  l’image  operationnelle  commune  des 
forces  canadiennes.  Elle  est  consideree  comme  un  moyen  permettant  aux 
commandants  d’estimer  et  d’interpreter  une  situation  dynamique  et  de  controler  son 
evolution. 

RDDC  a  conduit  un  effort  de  recherche  et  developpement  pour  aider  les  forces 
aeriennes  canadiennes  dans  l’implantation  d’une  situation  aerienne  generale 
dynamique  et  son  exploitation  pour  la  gestion  des  ressources  en  temps  reel  dans  les 
operations.  II  a  ete  decide  qu’afin  de  supporter  cet  effort  de  recherche  et 
developpement,  il  est  necessaire  de  selectionner  un  scenario  de  reference  ainsi  qu’un 
environnement  de  simulation. 

Pour  la  selection  du  scenario,  cinq  scenarios  ont  ete  analyses  : 

•  CF  Security  Support  to  the  Winter  Olympics  2010; 

•  Atlantic  Litoral  ISR  Experiment  (ALIX); 

•  Force  Planning  Scenario  #4:  Surveillance/Control  of  Canadian  Territory  and 
Approaches; 

•  Force  Planning  Scenario  #10:  Defense  of  North  America; 

•  Joint  Warrior  Interoperability  Demonstration  (JWID); 

•  Exercise  Final  Lance:  Atlantis. 

La  comparaison  entre  ces  scenarios  etait  basee  sur  cinq  aspects:  (1)  la  richesse  des 
informations,  (2)  le  realisme  tactique  du  point  de  vue  de  la  conduite  d’operations,  (3) 
les  capacites  et  possibility  des  amis  et  des  ennemies,  (4)  l’utilite  du  scenario  pour  la 
compilation  et  1’ exploitation  de  la  situation  aerienne  generale,  (5)  le  niveau  de  detail 
pour  developper  des  vignettes.  Le  scenario  Final  Lance  :  Atlantis  a  ete  selectionne 
pour  cette  etude. 
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Une  vignette  de  recherche  et  sauvetage  militaire  (CSAR)  a  ete  definie.  Ce  domaine 
d’ application  a  ete  choisi  car  il  presente  d’importants  defis  aux  planificateurs  de 
missions  a  cause  de  la  nature  hautement  dynamique  et  impredictible  des  applications 
CSAR. 

Une  fois  la  vignette  definie,  il  etait  necessaire  d’identifier  un  outil  de  simulation 
capable  de  derouler  la  vignette  et  de  supporter  les  travaux  de  recherche. 

Deux  outils  commerciaux  ont  ete  analyses  :  SADM  (Ship  Air  Defense  Model) 
developpe  par  British  Aerospace  (BAE)  et  Integrated  Anti-Ship  Missile  Defence 
Analysis  and  Simulation  Software  developpe  par  Tactical  Technologies  Inc.  (TTI). 
Deux  autres  outils  R&D  ont  ete  analyses  :  CASEATTI  developpe  par  la  section  de 
systemes  d’aide  a  la  decision  de  RDDC-Valcartier  et  Tenvironnement  KARMA 
egalement  developpe  a  RDDC-Valcartier. 

L’ analyse  de  ces  outils  a  ete  basee  sur  deux  types  de  criteres  :  le  premier  est  purement 
relie  au  genie  logiciel  et  le  second,  est  plus  oriente  vers  les  besoins  des  applications 
telles  que  les  fonctionnalites  relatives  a  la  situation  aerienne  generale  et  la  simulation 
CSAR.  Le  resultat  de  cette  comparaison  est  foumi  sous  forme  de  recommandations 
pour  la  selection  et  le  developpement  d’ outils  de  simulation  bien  adaptes. 


Allouche.  M.,  Belanger,  M.,  Maupin,  P.  2007.  RAP  Simulation  environment 
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1.  Introduction 


In  the  Canadian  Air  Force,  there  are  two  types  of  situational  awareness  systems  that 
“provide  commanders  at  all  levels  the  ability  to  see,  at  a  glance,  the  true  disposition  of 
assets  and  tracks  of  interest”:  the  Common  Tactical  Picture  (CTP)  and  the  Common 
Operational  Picture  (COP)  [1]. 

The  CTP  is  used  at  the  tactical  level.  It  represents  the  level  of  awareness  needed  for 
Air  Defence  Control  as  well  as  Tactical  Control  (TACON),  which  includes  the  control 
of  combat  and  combat  support  assets.  It  requires  real-time  access  to  live  feeds  from 
land,  surface  and  airborne  sensors.  However,  since  technology  limitations  preclude 
true  real-time  access,  near-real  time  access  involving  a  delay  measured  in  milliseconds 
is  considered  acceptable.  The  pre-defined  area  of  interest  covered  by  the  Canadian  Air 
Defence  Sector  (CADS)  has  been  identified  as  CADS  CTP. 

The  COP  is  used  at  the  operational  and  strategic  level.  It  provides  the  level  of  SA  that 
permits  timely  operational  and  strategic  decision-making.  The  COP  is  a  filtered  and 
simplified  representation  of  the  CTP.  A  digitized  representation  of  designated/relevant 
assets  and  tracks  of  interest  (TOIs),  delayed  by  a  matter  of  seconds  to  minutes,  is 
generated  to  augment  strategic  and  operational  levels  of  SA.  This  non-real  time 
picture  is  variously  termed,  according  to  different  areas  of  responsibility/interest,  the 
CANR  COP  (Canadian  NORAD  Region  COP),  the  NORAD  COP  or  the  CF 
(Canadian  Forces)  COP. 

The  notion  of  RAP  is  associated  with  the  concept  of  Canadian  Air  Force  COP  and  can 
be  defined  for  any  area  of  interest  that  is  pertinent  to  Canadian  Air  Force  operations. 
Accordingly,  the  RAP  can  be  considered  as  the  medium  to  monitor  the  situation  and 
develop  an  understanding  of  what  is  going  on  in  the  field.  To  provide  better  SA  for 
commanders,  the  RAP  needs  also  to  include  Friendly  Order  of  Battle,  Enemy  Order  of 
Battle  and  anything  else  that  can  be  considered  as  supporting  or  constraining  air 
operations.  In  fact,  the  concept  of  RAP  covers  the  identification  of  what  to  display 
(essential  air  data  requirements),  how  to  represent  it,  how  often  updates  need  to  be 
sent,  and  their  priority  at  the  strategic,  operational  and  tactical  levels. 

DRDC  conducted  an  R&D  activity  in  support  of  the  Canadian  Air  Force  by 
investigating  concepts  able  to  improve  the  implementation  of  a  dynamic  RAP  and  its 
exploitation  for  the  management  of  Canadian  Air  Force  resources  in  real-time 
operations.  In  order  to  support  our  R&D  effort,  the  following  were  required: 

•  a  scenario  that  could  be  used  for  reference  and  conceptual  implementation 
purposes;  and 

•  a  simulation  environment  able  to  support  the  implementation  of  such  scenario. 

This  report  describes  the  scenario  that  was  identified  for  our  RAP  project  and 
characterizes  the  simulation  environment  able  to  support  the  selected  scenario. 
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2.  Identification  of  a  case  study 


In  order  to  develop  and  demonstrate  the  concepts  of  the  RAP  compilation  and 
exploitation  project,  we  needed  a  scenario  supporting  a  type  of  operations  that 
provides  events  leading  to  the  compilation  and  exploitation  of  a  RAP.  Such  scenario 
had  to: 

•  be  small  enough  to  be  handled  during  the  project  and  complex  enough  to  provide 
relevant  RAP  compilation  and  exploitation  tasks; 

•  be  flexible  enough  to  allow  the  development  of  different  realistic  vignettes 
involving  a  broad  diversity  of  friendly  and  opposing  AF  courses  of  action  and/or 
AF  missions; 

•  maintain  a  good  tempo,  be  very  dynamic  in  execution,  and  involve  execution  of 
planning  tasks  with  the  possibility  of  a  high  level  of  non-deterministic  events. 

This  section  describes  the  approach  used  to  consider  and  compare  existing  scenarios 
and  identify  one  that  is  appropriate  to  our  needs.  A  vignette  was  developed  and  is 
presented  in  this  section. 


2.1  Scenarios  analyzed 

Five  scenarios  were  analyzed  to  identify  the  most  appropriate  for  our  needs  [2].  An 
overview  of  each  scenario  is  given  below. 

2.1.1  Scenario  1 :  CF  Security  Support  to  the  Winter  Olympics 
2010 

This  scenario  is  concerned  with  the  hosting  of  the  2010  Olympic  Games  in  Vancouver. 
Such  a  large  event  may  provide  a  venue  for  disruptive  terrorist  activities.  To  prevent 
such  threats  and  ensure  a  secure  environment,  close  cooperation  between  different 
governmental  and  non-governmental  organizations  is  required.  Event  organizers  must 
be  able  to  respond  in  a  timely  and  effective  manner  to  a  number  of  potential  situations, 
such  as  aircraft  infiltration,  biological  agent  release,  hidden  explosives,  etc.  It  is 
anticipated  that  DND  will  be  responsible  for  several  tasks  such  as  perimeter  defence, 
protection  of  vital  points,  surveillance,  C2,  communications  and  security. 

2.1.2  Scenario  2:  Atlantic  Littoral  ISR  Experiment  (ALIX) 

This  scenario  is  in  fact  three  separate  scenarios  that  provide  different  contexts  but  are 
related  by  similar  types  of  assets  (unmanned  aerial  vehicles  or  UAVs)  and  deployment 
of  these  assets. 
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Scenario  2a:  Domestic  Contingency  Operations  and  Aid  to  Civil  Power 

The  republic  of  Sakla  has  launched  a  satellite  which  failed  to  achieve  orbit.  It  is 
expected  that  the  satellite  might  re-enter  and  crash  over  the  Nunavut  Territory.  The 
republic  of  Sakla  has  dispatched  a  research  vessel  with  onboard  helicopter  to  the  area, 
and  there  are  suspicions  that  it  may  attempt  to  recover  the  technologically  sensitive 
sensor  payload.  In  addition,  local  authorities  have  environmental  concerns  since  the 
satellite  may  have  a  radioactive  fuel  cell  on  board.  Public  and  media  pressure  forced 
the  PM  to  direct  the  Minister  of  National  Defence  and  CF  to  deploy  elements  and 
assert  sovereignty  in  the  North.  The  CF  is  to  provide  support  to  other  government 
departments  (OGDs)  through  a  Joint  Task  Force  led  by  Commander  Canadian  Forces 
Northern  Area  (CFNA). 

Scenario  2b:  Peace  Support  Operations 

This  scenario  develops  a  conflict  between  two  bordering  states  of  Sakla  and  Granovia. 
Both  parties  agreed  to  a  UN-brokered  ceasefire  and  non-governmental  organizations 
are  intending  to  deploy  into  the  area  to  provide  humanitarian  support.  A  UN  force  is 
to  be  deployed  to  conduct  peace  support  operations.  The  Canadian  government  agreed 
to  deploy  CF  personnel  and  to  fund  aid  for  reconstruction  and  assistance. 

Scenario  2c:  Maritime  Security 

This  scenario  illustrates  a  conflict  in  which  the  Sakla  Republic  intends  to  actively 
challenge  international  law  by  fishing  inside  the  Canadian  Exclusive  Economic  Zone. 
The  event  is  expected  to  take  place  during  the  International  Environmental  Congress  in 
St.  John’s,  Newfoundland,  where  discussions  are  to  address  natural  resource 
conservation,  biodiversity,  and  the  establishment  of  world  protected  areas. 

2.1.3  Scenario  3:  Force  Planning  Scenario  #4: 

Surveillance/Control  of  Canadian  Territory  and  Approaches 

This  is  a  drug  smuggling  scenario.  A  narco-parastate  known  as  El  Diablo  has  been 
detected  smuggling  narcotics  of  all  varieties.  Its  main  market  is  North  America, 
followed  by  Europe.  Canada  is  part  of  its  North  American  market  and  is  also  used  as  a 
conduit  to  the  US  market.  Intelligence  analysis  revealed  that  a  large  quantity  of  drugs 
is  expected  to  reach  British  Columbia  from  Hong  Kong.  At  same  time,  a  load  of  drugs 
is  to  arrive  in  Nova  Scotia. 

2.1.4  Scenario  4:  Force  Planning  Scenario  #10:  Defence  of  North 
America 

A  new  supeipower  has  emerged  and  increasingly  threatens  the  West  for  domination  of 
the  world  stage.  Over  the  years  it  has  expanded  its  military  capabilities  to  include 
submarines  armed  with  ballistic  missiles  and  nuclear  weapons  that  target  North 
America.  It  has  also  developed  relationships  with  various  regimes  through  economic 
ties.  All  diplomatic  means  have  failed  to  solve  the  problem.  The  US  and  Canadian 
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governments  agreed  that  a  joint  Canada-US  force  has  become  necessary  to  eliminate 
this  threat  from  the  CANUS  region  and  to  establish  conditions  for  democratic  elections 
to  be  held  there. 

2.1.5  Scenario  5:  Joint  Warrior  Interoperability  Demonstration 
(JWID) 

This  is  a  US-hosted  exercise  based  on  fictitious  nations  in  a  real-world  setting  where 
the  US  and  the  NATO  and  AUSCANNZUKUS  allies  are  seeing  their  national  security 
and  economic  prosperity  threatened  by  a  coalition  of  terrorist  groups. 

2.1.6  Scenario  6:  Exercise  Final  Lance:  Atlantis 

This  scenario  was  used  in  2000  as  an  exercise  by  the  Canadian  Forces  Command  and 
Staff  College  (CFCSC)  to  teach  the  Canadian  Forces  Operational  Planning  Process 
(CFOPP)  and  allow  operational  knowledge  and  expertise  to  be  shared  among  CFCSC 
staff  and  students. 

A  crisis  has  developed  over  the  past  10  days  on  the  continent  of  Atlantis.  It  is  the 
result  of  years  of  growing  tensions  since  the  fall  of  1999,  and  has  now  erupted  into 
armed  conflict.  Individual  country  studies  are  provided  as  well  as  a  document  entitled 
“The  Manghalour  Peninsula  Crisis,”  to  provide  detailed  background. 

As  a  result  of  the  critical  situation  between  ORANGELAND/REDLAND  and 
BLUELAND,  the  UN  requested  the  Alliance  Council  to  consider  a  military  response 
to  help  resolve  the  crisis. 


2.2  Comparison  of  existing  scenarios 

In  order  to  identify  the  most  appropriate  scenario  for  our  needs,  different  aspects  need 
to  be  considered.  First,  we  need  a  level  of  detail  at  the  operational  level  similar  to  that 
required  for  real-world  operations.  Country  briefings  should  be  as  comprehensive  as 
possible  to  cover  geographic,  political,  economic  and  social  factors,  and  also  an 
assessment  of  the  location  and  strength  of  military  forces,  climate,  topography,  and 
transportation  and  communication  systems.  The  more  detailed  the  briefings,  the  more 
salient  factors  can  be  identified  and  the  more  deductions  can  be  made  to  assist 
planning.  The  scenario  should  contain  sufficient  air  force  elements  to  allow  the  Air 
Component  Commander  to  allot  and  employ  those  assets  independently.  The  first 
aspect  to  consider  is  richness  of  information. 

Although  most  of  the  elements  of  a  scenario  are  fictitious,  the  technology  and 
equipment  should  match  those  in  current  use  in  the  CF  for  training  and  education 
purposes.  Also,  one  should  beara  in  mind  that  the  next  employment  could  be  in  a  real- 
world  operation.  The  second  aspect  to  consider  is  tactical  realism  from  a  conduct  of 
operations  (tactical)  point  of  view. 
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Richness  and  tactical  realism  are  key  to  the  development  of  COAs  (for  both  friendly 
and  enemy  forces)  at  the  operational  level.  Also  required  is  sufficient  detail  at  the 
strategic  level  (geopolitical,  economic)  and  the  tactical  level  (military  forces, 
infrastructure).  The  third  aspect  to  consider  is  friendly  and  enemy  COAs. 

An  air  picture  is  a  dynamic  (validated  and  correlated)  display  of  tactical  locations  and 
tracks  of  airborne  systems  in  a  given  area  of  operations  (AOO).  Due  to  the  speed  and 
manoeuvrability  of  aircraft,  the  air  picture  was  normally  theatre-specific  and  was 
usually  dependent  on  one  major  radar  or  other  sensors  such  as  AWACS  and/or  long- 
range  radars.  With  the  advanced  processing  capabilities  and  portability  of  modem 
computing  systems  coupled  with  increased  data  transfer  through  data  links,  the  AF  has 
been  increasing  its  capability  to  fuse  real-time  correlated  data  from  a  number  of 
airborne,  ground-based  and  space-based  sensors  into  a  RAP.  This  enhances  reliability 
through  system  redundancy  and  expanded  airspace  coverage.  But  even  with  a  range  of 
sensors,  the  RAP  is  still  affected  by  different  natural  impediments  (clouds,  fog,  terrain, 
etc.).  Enemy  factors  are  also  at  play,  including  jamming  and  masking  by  terrain 
features,  although  masking  is  less  relevant  in  high-altitude  operations.  Actually,  the 
RAP  is  rendered  more  complex  by  elements  like  the  number  of  air  assets,  mission 
complexity,  airspace  characteristics,  unpredictable  enemy  air  forces,  sensor 
availability  and  natural  impediments  to  forming  the  RAP.  The  fourth  aspect  to 
consider  is  the  utility  of  the  scenario  for  compiling  and  exploiting  the  RAP. 

For  the  purposes  of  our  R&D  project,  we  needed  vignettes  that  provide  a  written 
description  of  the  execution  of  a  specific  tactical  mission  as  part  of  the  air  campaign 
for  a  given  scenario.  The  aim  of  developing  vignettes  is  to  map  the  conduct  of  the 
mission  as  planned  and  to  identify  alternate  COAs  at  each  stage  based  on  emerging  or 
changing  factors.  Examples  of  factors  that  may  contribute  to  an  unforecasted  change 
are  variable  weather  conditions,  different  topography  or  evolving  air  threats.  Each 
would  force  the  operational  planner  and,  to  a  much  greater  extent,  the  tactical  planner 
to  develop  contingencies  to  ensure  mission  accomplishment.  The  goal  of  vignette 
development  is  to  model  a  tactical  mission  for  simulation  purposes  based  on  a  series  or 
path  of  forecasted  events  and  branched  onto  different  paths  to  the  same  end  by 
unforecasted  events.  Therefore,  in  analyzing  each  scenario  for  its  ability  to  support 
vignette  creation,  emphasis  must  be  placed  on: 

•  The  number  of  air  assets  involved  for  both  friendly  and  non-friendly; 

•  The  predictability  of  those  assets  based  on  the  complexity  of  the  tactical  mission; 
and 

•  The  effects  of  environmental  factors  like  weather,  light  conditions  and  geography 
on  the  mission. 

In  essence,  the  more  dynamic  the  scenario,  the  more  event-altering  factors  are 
introduced  and  the  greater  the  number  of  non-determinant  paths  that  need  to  be 
created.  The  fifth  aspect  to  consider  is  the  level  of  detail  in  and  the  facility  of 
developing  vignettes. 
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Table  1  presents  the  compilation  of  the  scenario  analysis  general  ratings  considering 
these  five  aspects: 

•  richness  of  information  (called  scenario  details  in  Table  1); 

•  tactical  realism; 

•  capability  to  support  operational  level  COA  development  (called  ffiendly/enemy 
COAs  in  Table  1); 

•  utility  of  the  scenario  for  compiling  and  exploiting  the  RAP; 

•  level  of  detail  in  and  the  facility  of  developing  vignettes  (called  suitability  for 
vignettes  in  Table  1). 


Table  1.  Scenario  Evaluation  Table  [2] 


Scenario 

Scenario 

Details 

Olympics  201 0 

ALE 

MEDIUM 

Surveillance  /  Control  of  Canadian 
Territory  and  Approaches 

MEDIUM 

Defense  of  North  America 

MEDIUM 

JWID 

MEDIUM 

Atlantis 

GH 

Tactical 

Realism 

Fiiendly/Ene  my 
COA 

Possibilities 

Utility 

for 

RAP 

HIGH 

MEDIUM 

HIGH 

HIGH 

HIGH 

MEDIUM 

MEDIUM 

Suitability 

for 

Vignettes 


MEDIUM 


MEDIUM 


Table  1  indicates  that  the  Atlantis  scenario  provides  the  best  possibilities  for  thorough 
operational  level  COAs.  For  RAP  and  vignette  generation,  the  Atlantis,  JWID  or  (to  a 
lesser  extent)  Defence  of  Canada  scenarios  could  be  used  to  produce  a  complex  RAP 
consisting  of  a  variety  of  enemy  and  friendly  aircraft  plus  a  broad  range  of  RAP- 
feeding  sensors.  Coupled  with  an  equally  wide  range  of  geography  and  environmental 
options,  the  RAPs  produced  could  permit  the  generation  of  multiple  vignettes  with 
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varied  levels  of  complexity.  More  details  on  the  evaluation  of  the  different  aspects  for 
each  scenario  can  be  found  in  [2], 


2.3  Identification  of  a  vignette 

While  we  had  determined  that  the  North  Atlantis  scenario  offered  a  good  basis  for 
developing  a  vignette  that  would  be  effective  for  RAP  compilation  and  exploitation, 
we  still  needed  to  determine  which  vignette  would  meet  our  R&D  needs. 

The  vignette  had  to  be  effective  in  RAP  compilation  by  offering  rich  threat  attributes, 
a  dynamic  environment,  and  resource/asset  multiplicity  and  diversity.  In  terms  of 
RAP  exploitation,  it  had  to  be  at  an  operational-tactical  level,  distributed,  and 
dynamic.  As  mentioned  earlier,  the  realism  of  the  vignette  is  mandatory  (likelihood, 
compliance  with  AF  directions  and  policies).  The  area  of  operation  needed  to  be  in  a 
region  with  a  wide  variety  of  geographical  details. 

From  the  different  types  of  operations  that  may  occur  in  such  overall  scenario,  it  was 
considered  that  a  vignette  of  Combat  Search  and  Rescue  (CSAR)  operation  would  be 
very  appropriate  for  our  needs.  “Combat  Search  and  Rescue  (CSAR)  is  the  detection, 
location,  identification  and  rescue  of  downed  aircrew  in  hostile  territory  (in  crisis  and 
in  war,  and  when  appropriate)  isolated  military  personnel  in  distress,  who  are  trained 
and  equipped  to  receive  CSAR  support,  throughout  a  theatre  of  operations.”  [3]. 

A  CSAR  mission  presents  many  dynamic  challenges  for  the  mission  planner  in 
locating  and  extracting  in  a  hostile  environment.  Various  elements  must  be 
considered,  which  may  be  predictable  such  as  the  friendly  elements  of  detect  and 
rescue,  or  unpredictable  such  as  the  enemy  elements  of  detect  and  destroy.  Usually, 
mission  planners  use  air  and  ground  picture  inputs  to  make  their  decisions. 

It  is  important  to  mention  that  CSAR  is  different  from  SAR,  although  they  are  both 
considered  as  single  missions.  A  SAR  mission  is  usually  conducted  in  peacetime  and 
is  composed  of  two  distinct  phases:  the  search  phase  and  rescue  phase.  These  two 
phases  are  virtually  simultaneous.  Once  the  person(s)  is/are  located,  e.g.,  a  disabled 
ship  at  sea,  they  are  rescued  immediately  by  a  SAR-capable  helicopter.  In  CASR 
missions,  enemy  threats  are  always  a  factor.  Even  if  the  lost  person  is  located,  the 
rescue  must  be  carefully  planned  and  may  be  executed  several  days  after  due  to  the 
presence  of  threats  in  enemy  territory  where  the  downed  crews  or  lost  persons  are 
located.  As  expected,  the  technique  of  flying  a  predictable  search  pattern  over  enemy 
territory  would  be  fraught  with  risk.  Combat  search  techniques  would  include: 

•  Location  by  electronic  means  using  emergency  locator  transmitter  (ELT)  signals 
emanating  from  downed  aircraft.  ELT  signals  can  be  triangulated  by  satellites  like 
SARSAT  or  by  aircraft  flying  in  friendly  territory. 

•  Location  by  radio/secure  radio  transmissions  from  the  downed  crew  using  escape 
and  evasion  radios.  These  transmissions  can  be  voice,  in  which  case  the  GPS 
location  could  be  sent,  or  a  homing  signal  could  be  triangulated.  Again  these 
search  techniques  could  all  occur  over  friendly  territory. 
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•  Fly  tactically  supported  reconnaissance  assets  (UAVs  or  manned  aircraft)  through 
the  suspected  target  location  to  visually  spot  the  crew.  This  is  normally  not  done  to 
avoid  the  risk  of  losing  another  asset  and  also  because  the  downed  personnel  do 
not  know  whether  the  search  aircraft  is  friendly  or  not,  and  thus  will  try  to  avoid 
being  seen. 

Once  the  search  locates  the  lost  personnel,  the  rescue  phase  is  planned.  Usually,  the 
CSAR  will  be  conducted  under  the  umbrella  of  an  air  campaign  plan  and  will  not  be 
specifically  assigned  a  large  amount  of  support  assets,  unless  the  importance  of  rescue 
is  high  enough  to  warrant  a  separate  mission  with  significant  support  assets,  as  in  the 
case  of  the  USAF  F-16  pilot  (Captain  O’Grady)  downed  in  Bosnia  in  1995  [4]. 

The  primary  operational  task  of  rescue  is  to  locate,  communicate  with  and  recover 
downed  aircrew  and  isolated  personnel.  This  primary  task  can  be  broken  down  into 
three  sub-tasks.  Locate  the  aircrew  or  isolated  personnel  (survivor)  by  visual  or 
electronic  search  methods  to  pinpoint  the  survivor’s  location  and  permit  recovery. 
Communicate  with  the  survivor  by  radio  or  visual  signalling  to  authenticate.  Recover 
the  survivor  and  provide  medical  aid. 

Other  non-rescue  specific  operational  tasks  that  must  be  completed  to  accomplish  the 
primary  rescue  task  include: 

1 .  Provide  personnel  and  equipment  to  train  rescue  mission-ready  personnel; 

2.  Operate  efficiently  during  peacetime; 

3.  Airdrop  rescue  personnel  and  equipment; 

4.  Configure  rescue  equipment  for  deployment; 

5.  Provide  self-protection  for  rescue  assets; 

6.  Conduct  medical  evacuation  operations; 

7.  Provide  intelligence  support  directly  to  the  rescue  aircrew; 

8.  Respond  to  and  prepare  for  rescue  mission  execution; 

9.  Control  alert  and  airborne  rescue  missions;  and 

10.  Support  rescue  sortie  production. 

The  threat  environments  in  which  rescue  assets  operate  can  be  addressed  by  the  use  of 
supporting  aircraft.  Supporting  aircraft  providing  air-to-air,  air-to-ground  and 
suppression  of  enemy  air  defence  (SEAD)  coverage  can  degrade  the  threat,  either 
temporarily  or  permanently,  permitting  rescue  assets  to  enter  the  area  and  execute  the 
recovery.  Rescue  forces  may  be  augmented  by  these  supporting  systems  depending  on 
the  threat  environment,  distance  to  the  survivor  and  availability  of  assets. 

CSAR  operations  are  known  to  be  dangerous  and  complex.  They  normally  take  place 
in  enemy  territory  or  contested  areas.  Time  is  limited  and  knowledge  of  the  situation 
is  hard  to  find.  Such  operations  require  tailored  assets,  detailed  coordination  and 
timely  execution.  Irrespective  of  the  quantity  of  resources  available,  the  planning, 
coordination  and  control  requirements  for  CSAR  operations  are  considered  complex. 

CSAR  seems  to  be  an  appropriate  type  of  event  for  our  vignette  since  it  may  involve 
many  different  types  of  operations,  such  as: 
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•  Surveillance  of  a  specific  area,  including  RAP  compilation  and  mission  planning, 
monitoring  and  control  to  improve  surveillance; 

•  Target  detection,  which  includes  planning,  monitoring  and  control  of  missions  to 
improve  the  search; 

•  Recovery,  which  includes  planning,  monitoring  and  control  of  missions  to  recover 
the  target. 

These  operations  will  involve  different  types  of  AF  missions,  such  as: 

•  Use  of  UAVs  for  improved  search  and  surveillance; 

•  Combat  air  patrols  (CAP); 

•  Air  superiority; 

•  Electronic  warfare; 

.  SEAD; 

•  Close  air  support  (CAS); 

.  SAR; 

•  Search  and  extraction; 

•  Airborne  command,  control  and  communications  (ABCCC). 

These  different  operations  and  tasks  are  the  same  as  may  be  involved  in  a  domestic  air 
defence  and  surveillance  operation.  So  it  is  expected  that  the  findings  related  to  DSS 
for  RAP  compilation  and  exploitation  in  a  CSAR  will  be  directly  relevant  to  a  DSS  for 
RAP  compilation  and  exploitation  in  a  domestic  air  defence  and  surveillance 
operation.  For  example: 

•  Capabilities  developed  for  the  surveillance  of  a  specific  area  will  be  applicable  to 
the  surveillance  of  Canada  (e.g.,  North  Bay  or  Mac(P)  Mac(A)); 

•  Capabilities  developed  for  selecting  the  missions  to  be  executed  in  order  to 
accomplish  the  CSAR  will  be  applicable  to  COA  management  at  a  generic  level; 

•  Capabilities  developed  for  scheduling  resources  to  execute  the  plan  will  be 
applicable  to  real-time  scheduling  of  resources  for  AF  transport  missions  and  AF 
missions  to  support  other  environments; 

•  Capabilities  developed  to  monitor  execution  and  re-planning  will  be  applicable  to 
AF  operations  of  emergency  support. 
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Since  CSAR  operations  take  place  in  hostile  territory,  they  provide  the  level  of 
complexity  and  the  time  constraints  needed  to  demonstrate  our  concepts  for  the 
compilation  and  exploitation  of  the  RAP  while  dealing  with  an  operation  of  suitable 
scale.  Therefore,  we  will  use  a  CSAR  operation  for  our  project  in  RAP  compilation 
and  exploitation  for  Dynamic  Operations  Management. 

2.4  CSAR  vignette 

The  aim  of  vignette  development  is  to  describe  in  detail  the  sequence  of  events  for  the 
development  of  a  CSAR  mission.  The  mission  is  placed  into  a  fictional  scenario  - 
Final  Lance  -  Atlantis,  borrowed  from  the  Canadian  Forces  Command  and  Staff 
College  (CFCSC).  The  details  of  the  mission  include  all  methods  and  techniques  used 
to  compile  the  RAP  and  the  Recognized  Ground  Picture  (RGP)  using  airborne  assets. 
Although  they  are  separate  elements  of  the  same  mission,  many  of  the  RGP  assets  are 
airborne  and,  as  such,  are  part  of  the  RAP  [5,  6,  7], 

The  following  paragraphs  describe  the  CSAR  vignette  that  was  built  up  based  on  the 
Final  Lance  -  Atlantis  scenario  [8]. 

On  12  June,  the  second  day  following  the  commencement  of  the  Alliance  joint 
operations  to  secure  Blueland  and  expel  Coalition  invasion  forces,  a  Royal  Air  Force 
(RAF)  Tornado  call-sign  FIAWK27,  conducting  an  electronic  countermeasures  and 
reconnaissance  (ECR)  mission,  was  shot  down  over  the  Celtic  Straits  by  a  surface-to- 
air  missile  (SAM)  at  1608  hours.  The  crew  did  not  report  any  radar  activity,  so  it  was 
believed  that  the  missile  was  either  an  SA-8  or  SA-14.  Both  systems  had  been 
reported  in  the  area  as  part  of  the  Coalition  Airborne  Regiment  that  invaded  the 
Blueland  portion  of  the  Camrien  Peninsula  at  the  onset  of  hostilities. 

The  Tornado’s  wingman  reported  that  both  aircrew  ejected  safely  and  the  downed 
crew  reported  no  injuries  via  their  secure  survival  radio.  Shortly  after  the  downed 
crew  was  located,  a  CH-124  Sea  King  helicopter  from  Wahhabe  Airbase,  with  a  crew 
of  five,  was  sent  to  recover  and  evacuate  the  Tornado  crew.  At  approximately  1800 
hours,  in  the  process  of  extracting  the  downed  crew,  the  Sea  King  crashed.  The  crash 
was  attributed  to  mechanical  failure.  Two  members  of  the  Sea  King  crew  sustained 
non-life-threatening  injuries  that  have  limited  their  mobility  on  foot.  The  crash  site  is 
shown  in  Figure  1.  The  location  of  both  crews  is  5650N  2740W,  which  is 
approximately  60  nm  north  of  the  Brownland  town  of  Amitava  on  the  Camrien 
Peninsula. 

The  situation  was  forwarded  from  the  Combined  Air  Operations  Centre  (CAOC)  to  the 
ACC  for  consideration  in  the  Joint  Force  Commander’s  (JFC)  force  allocation  for  the 
upcoming  planning  period.  Following  an  initial  assessment  by  the  joint  staff,  the 
decision  briefing  resulted  in  the  ACC  issuing  the  following  tasking: 

Mission:  Alliance  AF  will  conduct  a  CSAR  mission  with  a  time  on  target  (TOT)  of 
NLT  13  June  1600  hrs.  Mission  will  be  part  of  ACC  campaign  plan,  which  for  that 
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period  is  to  maintain  air  superiority  over  Blueland  territory  using  IADS  and  AD 
fighters  and  to  support  MCC  operations  in  the  Atlantic. 
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Figure  1.  Tornado  and  Sea  King  Crash  Site 


In  order  to  fulfill  this  mission,  a  CSAR  Force  and  Joint  Force  were  allocated.  These 
forces  include  a  number  of  aircraft,  sensor  and  communication  systems  such  as  CF-18, 
Tornados,  AC-130,  CH-53,  AW  ACS,  KC-135,  etc.  (see  Phase  4  report  and  Annex  B 
for  more  details). 

COA  development  started  with  a  complete  threat  assessment  by  analyzing  the  enemy 
capabilities  relevant  to  the  mission.  The  analysis  considers  the  ABR  helicopter  re¬ 
supply  over  the  past  weeks  and  its  movement.  Based  on  Redland  doctrine  and 
movement  rates,  it  is  possible  to  estimate  the  location  of  ABR  in  the  next  24  hours  and 
its  impact  on  the  extraction  zone.  Special  assets  (SEAD)  should  be  dispatched  to 
negate  the  threat  and  impede  the  ABR  progress.  Outside  the  extraction  zone,  threats 
posed  by  other  enemy  assets  (MIG  31  CAP,  SA-10  and  SA-12  missile  batteries)  are 
identified  and  will  have  to  be  dealt  with  by  dispatching  Special  Forces  to  counter  the 
threats.  At  the  end  of  the  analysis,  all  enemy  locations  that  threaten  the  mission 
conduct  are  identified  and  solutions  are  worked  up. 
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Based  on  enemy  states  (ABR  lead  elements  and  associated  SAM  threats),  the  best 
method  of  reaching  the  goal  of  the  mission  (daylight  CSAR  extraction)  is  investigated. 
A  CAS  mission  is  necessary  to  deal  with  small  groups  of  enemy  troops  and  a  BAI 
mission  is  also  necessary  to  keep  the  ABR  forces  away  from  the  extraction  area. 

To  assure  the  safety  of  CSAR  assets,  local  air  superiority  would  need  to  be  achieved 
by  deploying  SEAD  and  offensive  counter-air  missions  to  negate  the  threat  of  SAM 
systems  during  the  extraction  operation. 

The  PC  designed  a  plan  to  meet  the  two  critical  mission  requirements:  air  superiority 
and  CSAR  extraction.  The  plan  includes  tasks  assignment  to  allocated  assets  to 
counter  the  enemy  threat  for  “efficiency  and  safety”  and  to  gain  and  maintain  local  air 
superiority.  An  example  of  a  typical  task  of  this  plan  is  “4  x  ECR  Tornado  -  SEAD  of 
Eaglevista  SAMs  from  five  (5)  minutes  before  to  five  (5)  minutes  after  mission  aircraft 
enter  AOO”. 

Seven  COAs  were  developed,  three  based  on  different  routings  for  the  CSAR  package 
and  four  based  on  TOT  relative  to  the  sequenced  availability  of  key  mission  assets. 

The  potential  routes  considered  are  depicted  in  Figure  2. 


BTY 

70 


NS8 


$  Downed  Aircrew  (5650N  27401V} 

Xk- 1  » 

Airport  with  radar 
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Figure  2.  Route  Options 
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The  COA  selected  was  code-named  “Op  Showdown/Beach”  and  was  assigned  the 
earliest  TOT  (1200  hours)  that  would  ensure  the  availability  of  all  necessary  air  assets. 
The  PC  and  staff  prepared  a  concept  of  operations  (CONOPS)  for  the  mission  and 
briefed  the  mission  and  following  COMAO  flow  plan  and  routings  to  the  CSAR  asset 
commanders  and  CAOC  staff.  An  extract  from  the  CSAR  COMAO  flow  plan  is  shown 
below.  The  figure  depicts  the  positions  of  CSAR  and  enemy  assets  at  1100  hours  (see 
[7]  for  a  full  version  of  the  plan  and  snapshots  of  the  scene  at  15-minute  intervals). 

1100 

•  Jammer  1-4  depart  AAR 

•  Zap  1-2  join  AAR  Track  A 

•  Sierra  1-4  (4  x  CF-18)  take  off  from  Bendeguz 

•  Bomber  1  -4  depart  AAR  Track  B 


lombe. 


>'1  x  AQAT! 
tl2  *CFh| 

PL-x  t®rna< 


Bendeg  * 


Wahh 


Blackpill 

FaranoT*^^ 


/sr~7*0  x  SA-*  (2*  b 
{  JJx^A'14  (jlnji 

aglevista-  ^ 


11:00 


1. -  W  J 

•  Downed  Aircrew  (5650fJ  2 
1  >  1  ^ 

±  Airport  with  radar  1 

’401V} 

W  !  "v 

+)  |  u 

d - r-T- - 

Figure  3.  1100  hours 
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In  order  to  show  all  the  information  exchanged  between  mission  assets  and  PC  and 
CAOC,  and  also  the  data  linked  RAP  and  RGP  from  AWACS  and  JSTARS  to  the 
CAOC,  a  synchronization  matrix  has  been  proposed  including  all  necessary 
information  related  to  events  that  occur  during  scenario  development.  Each  row  of  the 
matrix  contains  a  description  of  the  events  and  the  times  of  occurrence.  For  example, 
Zap  1-2  (2  x  Tornado  ECR)  take  off  from  Bendeguz,  mission:  target  area  SEAD  is 
considered  as  an  occurred  event.  The  matrix  shows  also  the  entity  or  entities  that  have 
caused  the  event  to  occur.  In  the  example.  Zap  1-2  are  the  entities  that  caused  the 
event  to  occur.  How  this  event  has  been  perceived  is  also  reported  in  the  matrix. 
Usually,  the  perception  corresponds  to  a  message  communicated  by  the  mission  assets 
including  RAP,  radio,  secure  phone,  voice,  and  datalink  communications.  In  the 
example,  the  take-off  of  the  two  Tornados  was  perceived  as  the  two  entities  are  on 
time.  Once  the  information  is  received  to  ensure  the  perception  of  an  event,  it  is 
important  to  report  how  this  event  is  interpreted  in  relation  to  the  mission  requirements 
and  execution.  In  the  example,  the  perception  and  interpretation  of  the  event  are  quite 
the  same  -  the  plan  is  on  schedule.  Finally,  the  matrix  shows  the  decisions  made  based 
on  the  perceived  events.  In  the  example,  any  state/capability  variances  are  reported  to 
the  PC  and  CAOC  in  order  to  ensure  that  the  entities  will  always  be  on  time  and  will 
not  hinder  mission  completion. 

An  extract  from  the  synchronization  matrix  is  shown  in  Table  2. 


Table  2.  Synchronisation  Matrix  (Example  1 ) 


Time 

Event 

Entity 

Perception 

Interpretation 

Decision/Actions 

1608 

Crew  of  two 
eject  from 

UK  Tornado 

E3 

AWACS 

ELT  bailout  tone 
picked  up  on  UHF 
guard  frequency. 
HAWK27  trackfile 
on  air  picture  scope 
indicates 
emergency. 

MC  assesses  tone  to  be 
legitimate  and 
correlates  to  HAWK  27 
mission  number  2527. 

Decision  made  to  report  to 
CAOC. 

1612 

Downed 
aircraft 
reported  to 
CAOC 

CAOC 

Datalink  message 
received,  followed 
by  secure  radio  call. 
RAP  updated  with 
distress  signal  from 
HAWK27. 

Assess  requirement  to 
recover  downed  crew 
ASAP.  Insufficient  time 
before  sunset  to  use 
CSAR  resources  at 

Nitric. 

Decision  made  to  utilize 

Sea  King  helicopter  at 
Wahhabe  due  to  proximity 
to  crash  site. 

1628 

Recovery 

tasking 

transmitted 

Sea 

King 

Unit  Ops 

Tasking  received 
via  secure  land-line 
phone. 

Assess  alert  status  and 
crew  readiness. 

Decision  to  launch  Sea 

King  13. 

1640 

Sea  King  13 

launch 

ordered 

Sea 

King  13 

PA  announcement 
received  in  Ready 
Room. 

Requirement  to  launch 
ASAP. 

Aircraft  manned  (crew  of  5) 
and  start-up  initiated. 

1705 

Sea  King  13 

launches 

from 

Wahhabe 

CAOC 

RAP  updated  with 

Sea  King  take-off 

Mission  commencing. 

Monitor  routing  and  timing. 

The  event  column  describes  the  event,  what  is  happening.  The  entity  column 
describes  the  person  or  unit/sub-unit  that  is  impacted  by  the  event.  The  Ops  Room  is 
represented  by  the  CAOC.  The  remaining  entities  are  considered  field  or  tactical  level. 
The  perception  column  describes  the  information  received  by  the  entity,  how  it  is 
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received  and  how  it  is  displayed.  The  interpretation  column  describes  how  the 
information  is  interpreted  by  the  entity.  The  decision/action  column  describes  the 
decision  or  actions  taken  by  the  entity. 

The  synchronization  matrix,  which  illustrates  the  execution  of  the  mission,  was  first 
proposed  in  an  ideal  context,  which  means  all  occurred  events  were  smoothly  handled 
and  the  mission  was  executed  successfully.  However,  in  a  real  context  forces  need  to 
consider  unpredictable  events  resulting  from  enemy  behaviour.  The  idea  was  to 
propose  three  events  that  were  not  supposed  to  occur  as  scheduled  and  to  analyze  their 
impact  on  mission  execution.  These  events  must  be  dealt  with  in  near-real  time  since 
there  is  no  time  to  stop  or  delay  the  mission.  Re-tasking  and  re-planning  are  therefore 
necessary. 

The  three  unexpected  events  are  the  following: 

1.  Inability  to  locate  enemy  ground  positions  due  to  cloud  and  terrain: 

The  sensors  used  were  affected  by  terrain  and  cloud,  causing  gaps  in  the  RGP 
including  critical  positions.  So  a  decision  needs  to  be  made  to  task  other 
sensing  means  to  cover  the  missing  areas  in  the  RGP; 

2.  Enemy  attack  helicopters  appear  in  the  CSAR  area: 

Due  to  inaccurate  information,  enemy  helicopters  in  the  CSAR  area  were  not 
reported.  The  presence  of  enemy  aircraft  endangers  the  CASR  assets.  A 
decision  is  needed  to  carefully  devise  a  plan  to  counter  the  most  threatening 
ECOA  in  the  area; 

3.  Enemy  SAM  system  in  ABR  rear  area  detects  the  CF-1 8  BAI  mission: 

The  routings  of  the  mission  were  carefully  planned  based  on  enemy  radar 
positions  and  ranges.  An  Atlantic  routing  was  planned  to  attack  enemy 
positions  10  minutes  before  the  CSAR  as  a  diversion.  Unfortunately,  enemy 
radar  detected  one  of  the  bombers  early  and  re-planning  is  needed  to  remedy 
the  situation. 

Adding  unforecasted  events  to  the  scenario  is  a  good  way  to  test  the  robustness  of  the 
mission.  The  more  robust  the  mission,  the  better  it  will  handle  new  and  unpredictable 
events.  It  is  also  important  to  see  how  the  decision  process  was  affected  by  such 
events,  including  retasking,  rescheduling  and  resynchronization  activities.  In  the 
synchronization  matrix,  a  colour  code  was  adopted  to  show  all  activities  related  to  the 
unforecasted  events.  Table  3  presents  two  extracts  from  the  synchronization  matrix 
which  show  changes  to  the  mission  due  to  the  three  new  events. 
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Table  3.  Synchronization  Matrix  (Example  2) 


Time 

Event 

Entity 

Perception 

Interpretation 

Decision/Actions 

1142 

Magic  confirms 

Jammer  2’s  call  that 
MiGs  are  CAPing 

Sierra  1 

Voice  reception 
on  secure  radio 

MiGs  still  in  CAP 

Continue  sweep  mission. 
Confirms  planned  CAP 
point  still  appropriate 

Updated  BAI  targeting 
information  passed  to 
Bomber 

Bomber 

Received  via 
datalink 

Updated 

coordinates 

received 

Weapon  systems  updated 
with  new  target 
information 

Updated  CAS 
targeting  information 
passed  to  Gunner 

Gunner 

Received  via 
datalink 

Updated 

coordinates 

received 

Weapon  systems  updated 
with  new  target 
information 

1143 

Zap  1  picks  up  and 
calls  SA-8  spike  on 
the  nose 

Zap  2 

Voice  reception 
on  secure  radio 

Within  SAM 
detection  range 

Monitor  own  RWR. 
Commence  visual  look¬ 
out  for  possible  SAM 
launches 

Bomber  2  reports 

RWR  SAM  search 
radar  strobe  from  the 
southeast 

Bomber 

1 

Voice  reception 
on  secure  radio 

Possible  detection 
by  enemy  radar 

Acknowledges  call. 

Monitors  own  RWR 

Spook 

Voice  reception 
on  secure  radio 

Need  to  correlate 
with  the  strobe  with 
the  RGP 

Acknowledges  call. 
Determines  that  strobe  is 
emanating  from  the  ABR 
rear  area. 

1144 

Bomber  2  reports  SA- 
8  tracking  spike  and 
performs  defensive 
manoeuvring 

Bomber 

1 

Voice  reception 
on  secure  radio 

Possible  launch  of 
SA-8  SAM  against 
Bomber  formation 

Acknowledges  call. 
Manoeuvres  with  Bomber 

2  to  provide  mutual 
support 

AWACS  detects 
unknown  slow  moving 
contacts 

Magic 

Surveillance 
scope  highlights 
unidentified 
tracks  moving 
forward  from  the 
ABR  rear  area 

Need  to  make 
identification  as 
soon  as  possible 

initiate  electronic 
identification  techniques 

Bomber  1  requests  use 
of  alternate  IP 
(northern  tip  of 

Camrien  Peninsula)  for 
BAI 

PC 

Voice  reception 
on  secure  radio 

Concurs  with 
request  given 
importance  of 
bombing  run  to 
delaying  the  ABR 
approach  toward 
the  extraction  area 

Grants  request  to  proceed 
to  alternate  IP  and  calls 
for  ROLEX  of  10  minutes 
to  both  BAI  and  CSAR 
missions 

1146 

Spook  updates  downed 
aircrew  location 
(received  from  Predator 
D 

Spook 

Receives 

Predator  data 
link  information 
from  Predator 

Conforms  with 
ground  mapping 
information  and 
voice  reports 

Pass  on  updated  RGP 
information  to  assets 

AWACS  attempts  to  ID 
or  correlate  unknown 
tracks 

Magic 

Comparison  of 
RAP  with  flow 
plan  and  enemy 
ORBAT 

Able  to  determine 
targets  are  medium 
to  heavy  lift,  single 
rotor  transport  or 
attack  helicopters 

Decision  made  that 
contacts  are  hostile  due 
to  lack  of  IFF  combined 
with  point  of  origin  and 
track 

AWACS  broadcasts 
position  of  “pop-up” 
targets 

Colour  legend: 

Black  -  Ideal  planned  events 

Green  -  Event  1:  Inability  to  locate  the  enemy  ground  positions  due  to  cloud  and  terrain 
Blue  -  Event  2:  Enemy  attack  helicopters  in  target  area 

Red  -  Event  3:  Enemy  SAM  system  in  ABR  rear  area  detects  the  CF-18  BAI  mission 
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3.  Identifying  simulation  environment  characteristics 
to  support  RAP  R&D 

Due  to  time  and  budget  constraints,  the  evaluation  of  simulation  tools  to  perform  R&D 
on  various  RAP  concepts  was  limited  to  two  commercial  products  [9]: 

•  SADM,  designed  by  British  Aerospace,  already  used  on  several  projects  at  DRDC 
Valcartier,  and 

•  Integrated  Anti-Ship  Missile  Defense  Analysis  and  Simulation  software,  designed 
by  Tactical  Technologies  Inc  (TTI)  of  Ottawa. 

and  two  R&D  tools  designed  at  DRDC  Valcartier: 

•  CASE  ATTI,  mainly  developed  by  the  Decision  Support  Systems  team,  and 

•  KARMA  environment,  developed  also  developed  at  DRDC  Valcartier. 

These  systems  were  evaluated  based  on  two  types  of  criteria:  the  first  type  being 
purely  software  engineering,  the  second  type  being  less  formal  but  more  oriented 
toward  application  needs  in  terms  of  RAP  functionalities  to  conduct  CSAR 
simulations. 


3.1  Software  engineering  criteria 

The  evaluation  of  these  systems  was  done  based  on  the  classified  evaluation  criteria 
proposed  by  Nikoukaran,  Vlatka  and  Ray  [10]:  vendor,  model  and  input,  execution, 
animation,  testing  and  efficiency,  output,  and  user. 


Simulation  Software  Evaluation  Criteria 


SOFTWARE 


Vendor 


Model  and 
Input 


Execution 


Animation 


Testing  & 
Efficiency 


Output 


User 


Figure  4.  Evaluation  criteria  for  simulation  software  [10] 


The  methodology  proposed  by  Nikoukaran  et  al.  is  relatively  detailed  and  proved  to  be 
efficient  and  easy  to  follow.  An  example  of  the  items  used  for  the  evaluation  under 
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each  criterion  is  given  below.  Not  all  items  in  the  underlying  hierarchy  were  used  in 
this  study.  Scores  were  aggregated  at  the  first  level  of  the  proposed  hierarchy.  As  an 
example,  for  the  model  and  input  criterion,  results  were  aggregated  for  the  following 
items:  library  of  reusable  modules,  model  building,  statistical  distributions,  coding 
aspects,  queuing  aspects  and  input,  leaving  aside  conditional  routing  aspects  that 
seemed  irrelevant  to  our  purpose. 


Model  and 
Input 


library  of 
reusable 
modules 


model 

building 

conditional 

routing 

statistical 

distributions 

coding 

aspects 


merging  of  I 
models  I 


I  hierarchical 
modelling 


standard 

fitting 

user  defined 


•  lomonts 


random  numbtr 
ganarators 

maant 

modularity 

dialogua 

boxas 

prompting 

1  queuing 

1  policies 

Input 

1  FIFO 

1  LIFO 

features  I  I  mode 


menu 

graphics 


keyboard 

scanner 

traceball 


programming 


link  to  other 
languages 


program 

generator 


global  vaiuas 


functions 


atlributas 


tools 

compilation 

spood 

sourco  cod# 

usar  defined 


Figure  5.  Model  and  Input  criterion  (Nikoukaran  et  at.  1 998) 


Details  and  scores  obtained  based  on  the  fine-grained  description  of  each  of  the  seven 
criteria  are  given  in  the  following  table  (more  details  can  be  found  in  [9]).  It  should  be 
noted  that  the  scores  were  attributed  by  one  person  and  may  not  exactly  reflect  the 
opinions  of  a  larger  set  of  users. 


Table  4.  Summary  of  the  evaluation  criteria 


Criterion 

SADM 

TTI 

CASE_ATTI 

KARMA 

Vendor  criteria 

39/43 

37/43 

21/43 

18/43 

Pedigree 

15/18 

16/18 

10/18 

6/18 

Documentation 

10/10 

9/10 

5/10 

4/10 

Support 

10/11 

9/11 

4/11 

5/11 
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Pre-purchase 

4/4 

3/4 

2/4 

3/4 

User  Criteria 

7/14 

11/14 

12/14 

10/14 

Simulation  type 

1/1 

1/1 

1/1 

1/1 

Orientation 

Ship  self 
defence 

Simulation  involving 
radar  IR  sensor  and 
manoeuvring  aircraft 
and  ship  with 
countermeasures 

AWW  in  blue 

sea 

Military  electro- 
optically  guided 
weapon 
engagements 

Hardware 

1/3 

3/3 

3/3 

2/3 

Security  device 

2/2 

1/2 

1/2 

1/2 

Operating  system 

1/2 

2/2 

2/2 

1/2 

Network  version 

1/2 

2/2 

2/2 

1/2 

Financial 

Consult 

Peter 

Osbourne 

1/3 

2/3 

3/3 

Required 

experience 

1/1 

1/1 

1/1 

1/1 

Software 

92/123 

117/123 

88/123 

85/123 

Model  and  Input 

20/34 

34/34 

29/34 

25/34 

Model  building 

7/14 

14/14 

11/14 

11/14 

Coding  aspect 

1/2 

2/2 

2/2 

2/2 

Queuing  policies 

1/2 

2/2 

2/2 

1/2 

Statistical 

distribution 

8/11 

11/11 

10/11 

7/11 

Input 

2/3 

3/3 

2/3 

2/3 

Library  of  reusable 
module 

1/2 

2/2 

2/2 

2/2 

Execution 

14/17 

17/17 

9/17 

14/17 

Speed  control 

2/2 

2/2 

1/2 

2/2 

Multiple  runs 

4/4 

4/4 

2/4 

4/4 

Automatic  batch  run 

2/2 

2/2 

2/2 

2/2 

Warm-up  period 

1/2 

2/2 

1/2 

1/2 

Reset  capability 

1/2 

2/2 

1/2 

1/2 

Start  in  non-empty 

1/1 

1/1 

1/1 

1/1 
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state 


Parallel  and 
distributed 

3/4 

4/4 

3/4 

3/4 

Animation 

28/29 

27/29 

18/29 

18/29 

Integrity 

2/2 

2/2 

1/2 

2/2 

Icons 

14/15 

14/15 

7/15 

7/15 

Running 

4/4 

3/4 

4/4 

4/4 

Screen  layout 

6/6 

6/6 

4/6 

3/6 

Development 

2/2 

2/2 

2/2 

2/2 

Testing  and 
efficiency 

13/20 

20/20 

16/20 

14/20 

Tracing 

1/1 

1/1 

1/1 

1/1 

Snapshots 

2/2 

2/2 

2/2 

1/2 

Step  function 

1/2 

2/2 

1/2 

1/2 

Breakpoint 

1/2 

2/2 

1/2 

1/2 

Validation  and 
verification 

1/3 

3/3 

2/3 

2/3 

Backward  clock 

1/1 

1/1 

1/1 

1/1 

Interaction 

1/2 

2/2 

1/2 

1/2 

Multitasking 

2/2 

2/2 

2/2 

1/2 

Conceptual  model 
generator 

1/2 

2/2 

2/2 

2/2 

Limits 

1/2 

2/2 

2/2 

2/2 

Display  feature 

1/1 

1/1 

1/1 

1/1 

Output 

17/23 

19/23 

16/23 

14/23 

Delivery 

5/6 

5/6 

2/6 

4/6 

Report 

4/4 

4/4 

3/4 

2/4 

Database 

1/3 

2/3 

3/3 

1/3 

Integration 

2/2 

2/2 

1/2 

1/2 

Analysis 

3/4 

3/4 

3/4 

3/4 

Business  graphics 

2/4 

3/4 

4/4 

3/4 
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Total  score 


138/180 


165/180 


121/180 


113/180 


3.2  Criteria  related  to  the  CSAR  scenario 

Based  on  the  vignette  needs,  the  additional  functionalities  needed  to  adapt  a  published 
RAP  system  for  the  needs  of  DRDC  Valcartier  in  combat  search  and  rescue  missions 
were  defined  as  follows. 

A.  Database  and  data  analysis  system  category 

1 .  A  database  system  for  the  registration  of  data  received  by  the  RAP; 

2.  A  GIS  link  to  georeference  the  RAP  data,  overlays  for  rivers,  roads,  commercial 
air  routes  and  other  items,  and  make  some  spatial  RAP  data  requests; 

3.  A  system  of  data  analysis  to  identify,  for  example,  significant  correlations; 

4.  Statistical  features  that  could  be  used  to  reproduce  stochastic  events; 

5.  An  inference  engine  that  may  include  additional  expertise  (e.g.,  reasoning 
applied  by  a  soldier  to  avoid  enemy  contact). 

B.  Graphical  user  interface  category 

6.  A  graphic  display  to  monitor  the  relevant  RAP  data; 

7.  A  3D  animation  system  to  visualize  in  real  time  the  RAP  data  and  a  simulation 
scenario; 

8.  A  simulation  system  to  validate  the  efficacy  of  some  scenarios  as  being  a 
potential  scenario  of  rescue. 

C.  Data  fusion  category 

9.  A  tracking  system  to  follow  targets  and  other  entities  of  interest; 

10.  A  threat  evaluation  system  to  determine  if  a  target  is  friendly,  neutral  or  an 
adversary; 

11.  A  projection  system  that  could  be  used,  for  example,  to  anticipate  where  a  target 
may  go  or  how  a  situation  may  evolve; 

12.  A  fusion  system  to  aggregate,  for  example,  the  information  coming  from 
different  sensors; 
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13.  A  planning  system  to  assign  and  schedule  the  resources  available  for 
surveillance,  search  and  rescue; 

14.  An  optimization  system  to  optimize  the  resource  allocation. 

D.  Simulation  system  category 

15.  Features  to  improve  the  realism  of  a  simulation  as  illumination  model. 

3.3  Evaluation  of  tools 

In  the  following  section,  we  briefly  present  software  descriptions  and  comments  on  the 
strengths  and  weaknesses  identified  as  far  as  RAP  and  CSAR  simulation  are 
concerned. 

3.3.1  SADM 

The  following  is  a  quotation  from  reference  [11].  The  “Ship  Air  Defence  Model 
(SADM)  is  described  as  a  software  tool  designed  to  simulate  the  defence  of  a  task 
group  against  one  or  more  attacking  aircraft,  cruise  missiles,  and/or  surface  targets.  It 
simulates  soft-kill,  hard-kill,  and  the  interactions  between  them. 

This  version  of  the  model  supports  a  task  group  of  up  to  10  ships.  Each  ship  can  have 
the  following  resources:  a  Command  and  Control  System  (C2),  a  Weapons  Control 
System  (WCS),  up  to  three  on-board  ES  (ESM)  Receivers,  up  to  five  conventional  or 
phased  array  Search  Radars,  an  IFF  System,  an  Infrared  Search  and  Track  (IRST) 
System,  a  Data  Fusion  engine,  up  to  16  Fire  Control  Radar  channels,  up  to  16 
illuminators,  up  to  6  types  of  hard-kill  weapons  (missiles,  guns,  and  CIWS),  up  to  6 
hard-kill  weapon  launchers,  a  Jammer  (Electronic  Attack  System),  offboard  active  and 
passive  decoys,  Mortar-  or  Rocket-launched  Chaff,  and  up  to  24  soft-kill  weapon 
launchers. 

The  model  supports  up  to  three  attacking  aircraft,  up  to  34  sea-skimming  or  high- 
diving  threat  missiles,  and  up  to  1 00  background  air  and  surface  targets,  with  the 
characteristics  of  each  threat  selected  independently.  Sixteen  of  the  threat  missiles  are 
independent,  and  may  be  placed  anywhere  with  respect  to  the  ships  under  attack.  The 
remaining  threat  missiles  are  associated  with  and  launched  by  the  threat  aircraft  or  by 
other  interacting  models  via  an  external  EILA  interface. 

The  model  may  be  used  in  both  the  open-ocean  and  littoral  environments.  For  littoral 
operations,  the  model  will  accept  DTED®  Level  0,  1 ,  and  2  terrain  elevation  data,  and 
modify  RF  sensor  (radar  and  ESM)  performance  based  on  the  resulting  terrain  height 
profiles.  The  optical  obscuration  effects  of  the  terrain  profile  are  also  included  in  the 
IRST  model.” 

It  is  interesting  to  note  that  the  baseline  SADM  system  can  be  extended  to  permit 
assessment  of  ground-based  air  defence  systems  and  UAV  system  survivability. 


22 


DRDC  Valcartier  TM  2006-702 


SADM  can  be  distinguished  from  the  other  simulation  tools  based  on  the  following 
characteristics. 


•  Support:  the  support  provided  by  the  company  that  produces  SADM  is  excellent 
because  it  was  able  to  provide  a  response  to  our  questions. 

•  Documentation:  the  documents  provided  with  SADM  are  of  high  quality 
compared  to  the  other  tools,  since  in  the  user  guide  we  found  not  only  information 
on  how  to  run  the  simulation  tool  and  its  options,  but  also  on  how  the  algorithms 
managed  the  model  components. 

•  Training:  this  company  provided  good  training.  The  cost  of  a  SADM  licence 
included  two  training  courses:  three  days  on  site,  and  two  more  days  at  a  later  date 
(i.e.,  3  to  6  months  after  the  purchase).  This  training  helps  users  learn  the  product 
quickly. 

•  Communication  with  other  simulation  tools:  like  KARMA,  SADM  is  compatible 
with  HLA  simulation. 

•  Simulation: 

•  Monte-Carlo  Simulation:  As  with  TTI,  a  Monte-Carlo  can  be  done  with 
SADM. 

•  3D  structure:  The  I/Q  RCS  profile  that  can  be  associated  with  a 
simulation  entity  permits  indirect  consideration  of  the  3D  structure  of  a 
simulation  entity. 

•  Command  and  Control  models:  This  model  mimics  the  operation  of  a 
Command  and  Control  System/Weapon  Control  System  for  both  area 
defence  and  self-defence  operations.  The  model  interfaces  directly  or 
indirectly  (through  the  Track  Management  System)  with  all  the  sensor 
and  weapon  systems  on  the  ship.  It  implements  the  Threat  Evaluation  and 
Weapons  Assignment  (TEWA)  process  for  both  hard-kill  and  soft-kill 
weapons. 

•  Data  link:  With  SADM  it  is  possible  to  define  a  data  link  between  ships 
or  between  aircraft. 

•  Topography:  SADM  considers  topography:  missiles  and  aircraft  can  fly 
over  mountainous  terrain,  and  terrain  affects  RF  signal  propagation  and 
IR  visibility. 

•  Survivability  and  lethality  model:  Like  TTI,  SADM  has  a  direct 
survivability  model  as  well.  SADM  incoiporates  the  SLAMS  V/L  model 
developed  at  DRDC-V.  The  user  specifies  a  vulnerability  model  for  each 
threat  missile,  aircraft  and  background  target,  and  the  lethality  model  for 
each  weapon,  and  SADM  calculates  the  results  of  each  engagement  based 
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on  endgame  geometry  and  the  V/L  files.  In  addition,  SADM  supports  a 
Lethality  Range  Factor  for  all  threat  missiles,  which  assesses  the 
probability  of  a  ship  being  hit  by  debris  from  a  destroyed  missile. 

For  the  extension  of  SADM  tools  toward  a  RAP  application,  the  following  needs  must 

be  addressed. 

•  Improve  SADM  extensibility:  Because  SADM  is  not  an  open-source  software,  to 
implement  a  novel  function  in  this  tool  the  company  BAE  should  code  it  or 
develop  an  interface  allowing  plug-ins  for  our  functions.  This  option  is  essential 
because  the  development  of  a  new  generation  of  RAP  requires  the  addition  of 
several  functions.  Consequently,  this  aspect  should  be  mentioned  in  the 
negotiations  with  BAE  to  authorize  access  to  the  code.  The  contact  manager  has 
already  confirmed  the  possibility  of  such  a  deal  with  the  company. 

•  Improve  the  debug  functionalities:  Because  the  SADM  codes  are  not  accessible,  it 
is  not  possible  to  debug  a  simulation  scenario  written  in  SADM.  If  access  to  the 
code  cannot  be  negotiated  with  BAE,  the  company  should  add  functionalities  in 
SADM  that  will  allow  users  to  debug  simulations  in  order  to  develop  it  into  a  RAP 
application. 

•  Improve  model  building:  The  interface  of  SADM  can  define  simulation  scenarios 
from  predefined  models  in  SADM,  but  it  is  not  possible  to  define  new  models. 
However,  for  some  functionalities  an  interface  is  provided  that  allows  models 
defined  by  the  user  to  be  plugged  in.  Again,  if  access  to  the  code  cannot  be 
negotiated  with  BAE,  the  company  should  add  functionalities  in  SADM  allowing 
new  models  to  be  built  in  order  to  develop  it  into  a  RAP  application. 

•  Improve  input  validation:  Currently,  a  minimal  validation  exercise  of  the  input 
parameters  used  in  SADM  can  be  done,  as  with  the  other  tools  selected  in  the 
present  study.  Each  simulation  tool  checks  if  the  input  parameters  are  within  a 
predefined  range,  but  does  not  verify  if  they  are  coherent  in  the  group  of 
parameters.  Consequently,  if  users  are  unaware  of  this  they  can  easily  crash  the 
simulation  tool. 

•  Simulation:  Improve  the  command  and  control  model  simulation:  since  SADM  is  a 
tool  dedicated  only  to  naval  attacks,  the  command  and  control  model  is  present  on 
a  ship.  Consequently,  it  may  not  be  located  on  another  entity  (e.g.,  aircraft).  For 
simulating  the  scenarios  selected  by  the  DRDC,  it  is  important  to  extend  the 
command  and  control  model  to  other  simulation  entities. 

•  Improve  the  IFF  model:  The  IFF  model  is  currently  very  simple.  It  receives 
interrogations  from  the  command  and  control  system  and  returns  responses  after  a 
brief  delay.  The  user  specifies  the  average  delay,  with  a  Gaussian  random 
component  added.  Since  all  emitters  in  the  model  except  ships  are  currently 
threats,  the  IFF  always  returns  a  “hostile”  result.  This  behaviour  will  change  as 
the  model  is  expanded.  However,  a  more  sophisticated  IFF  model  is  essential  to 
develop  a  RAP  application. 
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•  Improve  the  data  link:  Simulating  the  scenario  presented  in  the  previous  chapter 
requires  functionalities  for  establishing  communication  between  different  entities 
of  simulation.  In  other  words,  the  SADM  data  link  is  too  restricted  (ship  to  ship, 
aircraft  to  aircraft)  for  our  needs,  and  should  be  improved. 

•  To  develop  new  environmental  effect  model:  Entity  simulation  runs  can  be 
affected  not  only  by  the  atmosphere,  but  also  by  other  environmental  phenomena 
like  waves.  Improving  the  realism  of  the  simulations  necessitates  the  development 
of  other  effective  environmental  models. 

•  To  develop  a  new  kind  of  illumination  modelling:  Simulating  the  scenario  selected 
by  the  DRDC  requires  the  capability  to  reproduce  solar  and  lunar  illumination. 

For  example,  the  plan  for  a  daylight  rescue  operation  will  be  very  different  from 
the  plan  for  a  night  rescue.  For  example,  personal  camouflage  is  not  the  same 
during  the  day  and  at  night.  Therefore,  an  illumination  model  must  be  developed. 

•  To  develop  new  entities:  The  selected  scenario  demands  the  development  of  new 
SADM  simulation  entities  like  soldiers,  tanks,  etc. 

•  To  develop  facilities  that  include  different  layers:  For  simulating  the  scenario  by 
the  DRDC,  different  layers  such  as  road  and  land-use  should  be  considered.  It  is 
important  to  develop  new  facilities  that  permit  the  display  and  consideration  of 
these  layers  during  the  simulation. 

•  To  develop  facilities  for  zone  characterization:  For  simulating  the  selected 
scenario,  the  characterization  of  specific  areas  such  as  commercial  air  routes  and 
other  high-risk  areas  should  be  considered.  So  it  is  important  to  develop  new 
facilities  that  permit  the  display  and  consideration  of  these  zones  during  the 
simulation. 

•  To  improve  the  3D  aspect  of  the  simulation:  SADM  indirectly  considers  3D 
structure  via  the  I/Q  RCS.  It  would  be  important  to  have  functionalities  that  allow 
a  three-dimensional  structure  to  be  associated  with  each  simulation  entity.  It  is 
also  essential  that  the  different  models  consider  that  structure. 

•  To  eliminate  limitations  on  the  number  of  entities:  SADM  permits  the  simulation 
of  a  limited  number  of  simulation  entities.  For  DRDC  needs,  it  is  important  to 
eliminate  this  limitation. 

3.3.2  TTI 

On  the  TTI  web  site  [12],  the  products  are  described  as  follows. 

“The  Tactical  Engagement  Simulation  Suite  (TESS)  is  a  family  of  dynamic 
simulations  of  one-on-one,  three-dimensional  tactical  engagements.  Engagement 
types  include  guided  missiles  or  radar-controlled  guns  and  target  platforms  that 
employ  manoeuvres  and  combinations  of  electronic  countermeasures  for  self¬ 
protection  and  survival. 
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The  TESS  software  product  line  includes  simulations  of  engagements  involving 
various  types  of  Surface-To-Air  Missile  (SAM),  Air-to-Air  Missile  (AAM),  Anti-Ship 
Cruise  Missile  (ASCM)  and  radar  controlled  Anti-Aircraft  Artillery  (  AAA)  weapons. 
Target  platforms  include  manoeuvring  ships  and  aircraft.  Each  TESS  product  allows 
the  user  to  select  the  type  of  threat  weapon  angle  tracking  technique  from  a  menu  of 
various  angle  tracking  types.  It  also  allows  the  user  to  select  electronic 
countermeasures  from  a  menu  of  techniques,  including  chaff  clouds,  decoys,  and  on¬ 
board  jamming  techniques  that  include  noise,  range  gate  pull  off,  multiple  range 
targets,  velocity  gate  pull  off,  swept  amplitude  modulation,  countdown,  cross-eye  and 
cross-polar  techniques.  Most  combinations  of  countermeasure  techniques  can  be  used 
individually,  simultaneously  or  sequentially.  Models  of  specific  weapon  and 
countermeasure  systems  are  established  through  the  user's  selection  of  the  simulation's 
configuration  and  the  input  parameter  values.” 

TTI  can  be  differentiated  from  other  simulation  tools  based  on  the  following 
characteristics. 

•  Input  data:  In  addition  to  reading  input  data  interactively  or  reading  a  file,  it  is 
also  possible  to  download  those  data  from  other  databases  through  an  SQL  link. 
Also,  continuous  data  entry  by  Ethernet  for  hardware-in-the-loop  application  has 
been  delivered  in  custom  orders. 

•  Model  building:  TTI  products  are  available  in  the  form  of  an  open-source  code  of 
the  MathWorks  fifth-generation  languages  of  Matlab/Simulink.  So  the  simulation 
models  are  developed  via  graphical  programming,  and  the  program  makes  it  easy 
to  re-use  each  model  developed. 

•  Debug  option:  Simulink  has  an  integrated  debugging  environment  that  allows  the 
user  to  debug  the  simulation  model  along  with  the  process  of  development. 

•  Distributed  and  parallel  application:  TTI  is  the  sole  application  that  offers 
parallelization  and  distribution  of  applications. 

•  Simulation: 

•  Monte-Carlo:  Like  SADM,  Monte-Carlo  simulations  can  be  performed 
with  TTI. 

•  Tank  and  jeep  simulation  entities:  TTI  is  the  sole  application  that  offers 
simulation  of  tanks  and  jeeps. 

•  Satellite  simulation  entities:  TTI  is  the  only  application  that  may  also 
propose  the  simulation  of  satellite  entities. 

•  Movement  model:  With  TTI  it  is  possible  to  associate  movement  models 
not  only  with  ships,  as  with  SADM,  but  also  aircraft,  chaff,  flares  and 
decoys. 
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•  Wave  model:  TTI  includes  RF  scattering  and  multi-path  effects  from 
waves.  In  the  IR  domain,  atmospheric  events  such  as  attenuation  by 
weather  are  user-enterable. 

•  Geometry:  As  with  SADM,  it  is  possible  to  associate  a  3D  structure  with 
a  simulation  entity.  It  is  possible  to  link  CAD  3D  geometric  models  with 
TTI  sensor  models  in  a  Simulink  framework.  However,  code  should  be 
developed  to  automate  the  extraction  of  features. 

•  Lethality  and  survivability  model:  As  with  SADM,  the  TTI  lethality 
model  is  relatively  simple,  since  the  primary  objective  is  to  determine  the 
conditions  under  which  the  missile  can  be  launched  to  miss  its  target  by  a 
distance  such  that  the  warhead  fuse  is  not  triggered.  Hence,  lethality  is  an 
issue  only  if  this  primary  objective  is  not  achieved.  The  concept  of 
survivability  appears  through  the  computation  of  missile  miss  distance 
and  probability  of  platform  survival  based  on  step-by-step  computation  of 
missile  fly-out,  including  all  linear  and  non-linear  interactions  between 
the  missile  and  its  fire  control  system,  as  well  as  the  target  platform  with 
its  manoeuvres  and  self-defence  measures. 

For  the  extension  of  TTI  tools  toward  a  RAP  application,  the  following  needs  must  be 

addressed. 

•  Improve  the  TTI  performance:  Since  TTI  simulation  executes  interpreted  code,  the 
execution  of  the  simulation  is  relatively  slow.  To  improve  simulation 
performance,  conversion  of  the  code  into  C  language  using  the  Matlab/Simulink 
Real  Time  Workshop  is  essential.  This  induces  a  duplication  of  the  code  (C  and 
Simulink  versions),  which  may  be  difficult  to  manage.  For  the  needs  of  DRDC,  it 
will  be  appreciated  if  TTI  performance  can  be  improved  directly  within  Simulink. 

•  Improve  the  TTI  documentation:  Understanding  the  TTI  documentation  requires 
the  ability  to  program  graphically.  A  brief  introduction  to  graphic  programming  is 
essential  for  a  better  understanding  of  the  documentation  provided. 

•  Simulation:  Improve  the  command  and  control  model  simulation:  As  with  SADM, 
the  command  and  control  model  is  present  only  on  a  ship.  To  simulate  the 
scenarios  selected  by  DRDC,  it  is  important  to  extend  the  command  and  control 
model  to  other  simulation  entities. 

•  Develop  the  IFF  model:  TTI  does  not  contain  an  IFF  model,  which  is  necessary  to 
meet  DRDC  needs. 

•  Develop  the  data  link:  TTI  does  not  have  a  data  link  model.  For  simulating  the 
selected  scenario,  it  is  important  to  develop  this  model. 

•  Develop  simulation  model  considering  topography:  Presently  in  TTI,  topography 
is  not  taken  into  account.  For  instance,  when  simulating  the  scenario  selected  by 


DRDC  Valcartier  TM  2006-702 


27 


DRDC,  topography  is  an  important  parameter  to  consider  when  simulating  the 
landing  of  an  airplane.  Topography  should  therefore  be  considered. 

•  Develop  new  environmental  effects  model:  As  observed  for  SADM,  improving  the 
realism  of  simulations  necessitates  the  development  of  other  effective 
environmental  models  (e.g.,  ice  storm). 

3.3.3  CASE_ATTI 

The  documentation  on  CASEATTI  [13]  describes  this  tool  as  follows:  “The 
designer/developer/user/operator  of  Level-One  Data  Fusion  (LIDF)  systems  need 
capabilities  that  allow  them  to  quantitatively  assess  if  the  algorithms  and  techniques  of 
a  proposed  LIDF  system  are  suitably  working.  In  that  respect,  a  highly  modular, 
structured,  and  flexible  test  bed,  called  CASE  ATTI  (Concept  Analysis  and 
Simulation  Environment  for  Automatic  Target  Tracking  and  Identification),  has  been 
developed  at  DRDC  Valcartier  as  a  proof-of-concept  demonstrator  to  achieve  the 
continuing  exploration  of  LIDF. 

Besides  the  possibility  of  using  real  data,  CASE  ATTI  has  a  high-fidelity  stimulator 
that  emulates  the  behaviour  of  real  targets,  sensor  systems  and  the  meteorological 
environment,  allowing  the  user  to  create  and  edit  test  scenarios  with  multiple 
ships/sensors/targets.  The  ships  can  be  stationary  or  moving  along  user-predefined 
paths.  One  or  several  sensors  can  be  assigned  to  each  ship  (currently,  the  stimulation 
module  supports  surveillance  radar,  IFF,  ESM  and  IR  sensor  and  link  simulations). 
Targets  are  created  with  user-predefined  3D  trajectories  and  attributes. 

One  of  the  main  requirements  of  the  CASE  ATTI  test  bed  has  also  been  to  provide  the 
algorithm- level  test  and  replacement  capability  (required  to  study  and  compare  the 
technical  feasibility,  applicability  and  performance  of  advanced,  state-of-the-art  LIDF 
techniques)  where  the  user  can  switch  between  all  available  algorithms  in  the 
CASE  ATTI  library  without  re-coding  and/or  re-compiling.  The  LIDF  system 
module  supports  a  wide  variety  of  LIDF  architecture  types,  varying  from  a  simple 
single  sensor  tracker  to  an  arbitrary  complex  multiple  sensor  topology  (including 
contact-level,  track-level  or  hybrid  fusion  architecture  types). 

A  performance  analysis  database  retains  archives  of  all  manipulated  data.  A 
performance  evaluation  module  provides  tools  to  assist  the  quantitative  assessment  of 
LIDF  systems  performance.  A  user  interface  module  supports  all  interactions  with  the 
users/operators.” 

It  is  possible  to  distinguish  CASE  ATTI  compared  to  the  other  simulation  tools  from 
the  following  characteristics: 

•  Developer  guide:  CASE  ATTI  contains  a  good  developer  guide.  This  guide  can 
be  useful  if  it  is  decided  to  extend  CASE  ATTI  toward  a  RAP  application. 

•  Good  extensibility:  Like  KARMA,  CASE  ATTI  is  available  in  the  form  of  an 
open  object-oriented  source  code.  This  facilitates  the  extension  of  this  tool  toward 
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a  RAP  application.  Because  CASEATTI  is  compiled  code,  performance  should 
be  better  than  TTE 

•  Database  connection:  CASE  ATTI  possesses  a  link  to  ORACLE  database.  This 
database  provides  many  facilities  for  data  storage  and  retrieving  and  manipulating 
output,  input  and  other  data  concerning  the  model.  Furthermore,  for  the  majority 
of  GIS,  it  is  possible  to  make  a  connection  to  this  database. 

•  Statistical  features:  Like  TTI,  CASE  ATTI  provides  good  statistical  features. 

This  tool  supplies  some  standard  statistical  distributions  such  as  normal  and 
exponential,  which  facilitate  the  acceptance  of  input  data  modelled  according  to  a 
statistical  distribution.  It  also  supplies  functionalities  to  fit  data  into  a  distribution. 
Furthermore,  CASE  ATTI  provides  different  random  number  streams.  It  is  also 
possible  to  define  our  own  random  generator.  Finally,  in  CASE  ATTI,  all 
functionalities  needed  for  the  implementation  of  Monte-Carlo  simulation  are 
available. 

•  Business  graphics:  CASE  ATTI  offers  the  best  possibilities  for  graphic 
management  (i.e.,  a  graphic  may  be  changed  at  each  change  of  a  model  run). 

•  Simulation: 

•  Track  management:  As  described  in  the  preceding  section,  CASE  ATTI 
provides  the  algorithm-level  test  and  replacement  capability  (required  to 
study  and  compare  the  technical  feasibility,  applicability  and  performance 
of  advanced,  state-of-the-art  L1DF  techniques),  where  the  user  can  switch 
between  all  available  algorithms  in  the  CASE  ATTI  library  without  re¬ 
coding  and/or  re-compiling.  The  L1DF  system  module  supports  a  wide 
variety  of  L IDF  architecture  types,  varying  from  a  simple  single-sensor 
tracker  to  an  arbitrary  complex  multiple-sensor  topology  (including 
contact-level,  track-level  or  hybrid  fusion  architecture  types). 

•  Wave  model:  As  with  TTI,  some  sensor  models  take  into  account  a  wave 
effect. 

For  the  extension  of  CASE  ATTI  tools  toward  a  RAP  application,  the  following  needs 

must  be  addressed. 

•  Improve  documentation:  The  CASE  ATTI  documentation  describes  how  to  use 
the  C  ASE  ATTI  interface,  but  a  description  of  the  different  algorithms  that  can  be 
selected  is  not  available.  To  extend  this  application  toward  a  RAP  application  it 
would  be  important  to  make  this  possible. 

•  Improve  support:  CASE  ATTI  has  no  specific  support  department.  It  is  the 
developer  who  should  answer  questions  from  users.  Because  developers  are  often 
busy  with  other  work,  a  quick  answer  may  not  always  be  provided.  In  the 
eventuality  that  this  tool  is  extended  toward  a  RAP  application,  it  would  be 
essential  to  improve  user  support. 
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Improve  communication  with  other  simulation  tools:  CASEATTI  is  not 
compatible  with  HLA  simulations.  Since  RAP  application  may  involve  several 
types  of  simulation,  it  is  essential  to  develop  this  option. 

Improve  animation:  In  CASE  ATTI,  a  simulation  entity  is  modelled  as  a  cylinder. 
The  size  of  the  cylinder  can  be  defined,  but  during  animation,  simulation  entities 
are  represented  only  by  single  points.  Accurate  reproduction  of  the  DRDC 
scenario  will  require  the  development  of  functionalities  for  3D  animation. 

Simulation: 

•  Develop  Monte-Carlo  simulation:  Too  validate  the  performance  of  the 
selected  scenario,  it  would  be  important  to  implement  Monte-Carlo 
simulations. 

•  Improve  the  simulation  of  each  entity:  In  CASE  ATTI  it  is  possible  to 
simulate  a  generic  platform.  This  type  of  generic  approach  is  used  to 
reproduce  the  common  properties  of  the  different  platforms,  e.g., 
displacement.  However,  more  specific  properties  such  as  aircraft 
turbulence  may  not  be  simulated.  The  improvement  of  simulation 
realism  necessitates  the  development  of  those  specific  properties. 

•  Add  a  movement  model:  In  CASE  ATTI  no  movement  model  is 
available.  For  simulating  the  scenario  selected  by  DRDC,  the  movement 
model  may  influence  the  planning  of  rescue  operations.  A  movement 
model  should  therefore  be  developed. 

•  Add  a  survivability  and  lethality  model:  CASE  ATTI  does  not  contain 
survivability  and  lethality  models.  The  realism  of  the  DRDC  scenario 
simulation  may  be  enhanced  by  the  development  of  a  survivability  and 
lethality  model. 

•  Improve  the  command  and  control  model:  CASE  ATTI  implements  only 
a  part  of  the  command  and  control  system  (i.e.,  track  management,  data 
fusion,  etc.).  However,  there  are  no  weapon  control  models  that  permit, 
for  example,  the  launch  of  a  missile  according  to  threat.  An  improvement 
would  consist  of  taking  into  account  this  aspect. 

•  Improve  the  3D  structure  management:  In  CASE  ATTI,  only  some 
sensors  may  consider  the  cylinder  associated  with  a  simulation  entity.  It 
would  be  important  to  develop  functionalities  for  associating  a  cylinder 
and  especially  a  three-dimensional  structure  with  each  simulation  entity. 
Furthermore,  it  would  be  essential  to  consider  this  3D  structure  in  the 
different  models. 
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3.3.4  KARMA 


According  to  reference  [14],  “KARMA  is  a  process  for  carrying  out  engagement- level 
modelling  and  simulation  of  weapon  systems.  The  main  objective  of  this  process, 
named  KARMA,  is  to  provide  a  method  and  software  architecture  to  model  and 
simulate  weapon  system  engagements.  The  envisioned  mission  of  KARMA  products 
is  to  support  the  improvement  of  the  military  platforms  self-protection.  The  main 
features  of  the  KARMA  process  are  the  incorporation  of  a  structured  method  for 
modeling  the  simulation  actors;  a  component-based  modeling  strategy  allowing 
various  levels  of  detail;  an  autonomous  simulation  environment  which  shall  include 
planning,  scripting  and  analyzing  capabilities;  a  component-based  simulation 
architecture  permitting  various  levels  of  detail;  and  a  simulation  architecture  flexible 
enough  to  ensure  component  interoperability  and  reusability.  Although  KARMA  has  a 
very  broad  reach,  its  extent  was  limited,  to  engagements  between  IR  guided  weapon 
systems,  aircraft  and  countermeasures.” 

It  is  possible  to  differentiate  KARMA  from  the  other  simulation  tools  based  on  the 
following  characteristics. 

•  Development  process  documentation:  KARMA  is  the  sole  application  for  which 
the  development  process  is  documented  in  the  reference  [15].  This  documentation 
could  be  useful  if  we  decide  to  extend  KARMA  toward  a  RAP  application. 

•  Developer  guide:  KARMA  contains  a  developer  guide  which  is  less 
comprehensive  than  CASEATTI,  but  it  could  be  useful  if  it  is  decided  to  extend 
KARMA  towards  a  RAP  application. 

•  Good  architecture:  KARMA  possesses  a  very  good  architecture  to  which  new 
functionalities  can  be  added  easily. 

•  Extensibility:  Like  CASE  ATTI,  KARMA  is  available  in  the  form  of  an  open 
object-oriented  source  code.  Therefore,  it  is  easier  to  extend  this  tool  toward  a 
RAP  application.  Since  KARMA  is  compiled  code,  its  performance  should  be 
better  than  that  of  TTI. 

•  Communication  with  other  simulation  tools:  Like  SADM,  KARMA  is 
compatible  with  HLA  simulations. 

•  XML  input  and  output  files:  KARMA  input  and  output  files  are  saved  in  XML 
format. 

•  Support:  The  KARMA  team  has  no  support  department,  although  they  provide 
high-quality  service  and  answer  questions  promptly. 

For  the  extension  of  KARMA  tools  toward  a  RAP  application,  the  following  needs 
must  be  addressed. 
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•  Documentation:  As  with  CASE-ATTI,  the  documentation  on  KARMA  describes 
the  utilities  of  the  KARMA  interface  but  not  the  model. 

•  Tests:  The  unit  tests  of  KARMA  are  not  complete.  Only  the  interface  (KARMA 
studio)  was  tested.  Also,  this  tool  has  no  integration  system  and  acceptance  tests.  It 
would  be  important  to  improve  this  aspect  to  demonstrate  the  robustness  of 
KARMA.  Test  for  portability:  special  care  was  taken  to  develop  code  that  is 
platform-independent,  but  portability  has  not  yet  been  tested.  Again,  it  would  be 
important  to  validate  this  aspect  before  selecting  this  tool. 

•  Screen  layout:  KARMA  doesn’t  provide  an  editor  to  create  screen  layout. 
Therefore,  it  is  not  possible  to  generate  multiple  screen  layouts  and  switch 
between  screens  as  well  as  their  printout.  To  facilitate  analyzing  the  simulation  of 
the  selected  scenario,  the  development  of  an  editor  would  be  appreciated. 

•  Simulation: 

•  Improve  the  3D  structure  management:  In  KARMA,  it  is  possible  to 
associate  a  sphere  or  cube  with  a  simulation  entity.  These  structures  are 
considered  by  the  collision  model  only,  and  not  by  the  sensor  model.  In 
this  case,  the  sensors  may  perceive  only  a  single  point.  It  would  be 
important  to  provide  functionalities  permitting  the  association  of  a 
cylinder,  a  sphere  and  a  three-dimensional  structure  for  each  simulation 
entity.  Also,  it  would  be  essential  that  the  different  models  consider  the 
3D  structure. 

•  Platform  command  and  control:  In  KARMA,  there  is  no  command  and 
control  model.  For  simulating  the  scenarios  selected  by  DRDC,  it  would 
be  important  to  develop  a  command  and  control  model. 

•  Improve  trajectory  management:  The  simulation  entities  for  which  a 
trajectory  is  pre-defined  are  not  yet  implemented  in  KARMA.  For  DRDC 
needs,  it  is  essential  to  implement  this  feature. 


3.4  Comparison/discussion 

The  simulation  tools  that  were  evaluated  can  be  grouped  in  two  main  categories: 
commercial  products  (SADM  and  TTI)  and  DRDC  developments  (CASEATTI  and 
KARMA).  In  the  commercial  category,  these  are  the  main  points  that  have  been 
observed.  Being  the  product  of  greater  input  resources,  the  commercial  tools  clearly 
achieve  higher  scores.  Documentation,  support  and  animation  features  are  better  in  the 
commercial  simulation  tools  than  in  the  DRDC  tools.  A  comparison  of  the  two 
commercial  simulation  tools  yielded  the  following  observations.  Unlike  TTI,  SADM  is 
able  to  take  topography  into  account,  it  contains  an  IFF  model,  and  it  can  simulate  the 
data  link.  On  the  other  hand,  SADM  has  the  following  limitations.  The  number  of 
simulation  entities  is  limited;  SADM  is  essentially  dedicated  to  naval  attacks,  so  the 
IFF  model  is  relatively  simple  (ship  =  friend,  other  platform  =hostile);  and  the 
command  and  control  model  can  be  associated  only  with  a  ship.  Unlike  SADM,  TTI 
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is  an  open-source  software.  Therefore,  a  simulation  can  easily  be  debugged.  The  TTI 
development  environment  (Simulink)  permits  easy  building  of  other  simulation 
models.  TTI  can  supply  more  simulation  entities  (tank,  jeep  and  soldier)  than  SADM. 
TTI  is  able  to  take  wave  effects  into  account.  TTI  is  a  portable  application.  With  TTI, 
it  is  possible  to  associate  a  movement  model  with  threats.  On  the  other  hand,  TTI  has 
certain  limitations.  As  with  SADM,  the  current  command  and  control  model  is 
implemented  only  for  the  ship.  And  because  TTI  is  interpreted  code,  its  simulation 
performance  does  not  equal  that  of  SADM. 

Both  tools  developed  by  DRDC  are  open  object-oriented  source.  Their  object-oriented 
technology  ensures  good  extensibility  and  reusability  of  the  code.  The  source  code  is 
registered  according  to  the  DRDC  programming  standard,  so  it  is  easier  to  understand, 
read  and  use  in  conjunction  with  other  DRDC  tools.  A  comparison  of  these  two  DRDC 
tools  yielded  the  following  observations.  Unlike  KARMA,  the  portability  of 
CASEATTI  has  been  tested.  CASEATTI  contains  the  required  functionalities  in  the 
source  code  to  implement  Monte-Carlo  simulation.  In  CASE  ATTI,  it  is  possible  to 
modify  a  scenario  while  another  is  running.  CASE  ATTI  contains  a  database  link. 
Some  sensor  models  of  CASE  ATTI  can  consider  the  cylinder  that  may  be  associated 
with  a  simulation  entity.  CASE  ATTI  contains  an  IFF  model  and  supplies  a  track 
management  system.  CASE  ATTI  is  able  to  consider  the  curvature  of  the  earth.  In 
CASE  ATTI  it  is  possible  to  assign  a  pre-defmed  trajectory  to  a  simulation  entity.  As 
for  KARMA,  the  development  team  answered  requests  more  promptly.  The 
development  process  of  KARMA  is  documented.  KARMA  is  compatible  with  HLA 
simulation.  In  KARMA,  it  is  possible  to  control  the  speed  of  each  run.  KARMA 
contains  a  collision  model  that  is  able  to  take  into  account  the  sphere  or  the  cube 
associated  with  a  simulation  entity.  KARMA  supplies  various  weapon  systems  and 
contains  a  motion  model. 

Now,  the  two  main  questions  are: 

1.  Could  the  development  of  a  new-generation  RAP  system  be  assured  by  extending 
existing  command  and  control  simulation  tools? 

2.  If  yes,  which  of  the  tools  examined  here  would  be  preferable? 

The  following  are  the  essential  elements  to  help  answer  question  1 : 

RAP  functionalities  1,  3,  4,  6,  7,  8,  9,  10,  11,  12,  13  and  15  (see  list  in  section  3.2) 
needed  by  DRDC  can  be  partially  or  totally  fulfilled  by  the  simulation  tools  examined 
in  the  present  study.  However,  the  following  functionalities  are  not  fulfilled.  Number 
14  concerns  the  need  for  an  optimization  module.  To  simulate  the  scenario  selected  by 
DRDC,  it  is  important  to  find  a  solution  to  this  problem.  In  fact,  this  scenario  involves 
a  lot  of  constraints  that  we  should  consider  during  the  planning  operation,  for  example, 
limited  flying  time.  To  achieve  a  high  degree  of  success  in  planning,  an  optimization 
model  capable  of  taking  these  different  constraints  into  account  is  needed.  So  it  is 
recommended  that  this  aspect  be  resolved.  Functionality  5  concerns  the  inclusion  of  an 
inference  engine  in  the  RAP  application.  This  option  is  important  when  DRDC 
decides  to  include  a  reasoning  aspect  in  the  RAP  application  (e.g.,  reasoning  applied 
by  a  soldier  to  avoid  enemy  contact).  Again,  it  is  recommended  that  consideration  be 
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given  to  how  this  functionality  can  be  added.  Functionality  2  concerns  the  possibility 
of  having  a  GIS  link  in  the  RAP  application  to  allow  the  following  major  operations: 
georefencing  RAP  data,  displaying  different  overlays  like  roads  and  rivers,  assigning 
some  characteristic  to  commercial  air  routes,  making  space-time  requests  (e.g.,  in  a 
rescue  operation,  finding  the  nearest  bridge). 

To  simulate  the  scenario  selected  by  the  DRDC,  further  study  is  recommended  to 
answer  the  following  questions: 

3.  Which  GIS  could  be  used  to  support  the  RAP  development? 

4.  Which  simulation  tool  would  be  compatible  with  this  GIS? 


As  the  treatment  of  spatial  data  is  central  to  the  RAP  application,  it  is  essential  that 
questions  3  and  4  be  answered  before  question  1 .  But  even  without  further  study  it  is 
already  clear  that  the  simulation  tools  examined  here  fulfil  many  of  the 
functionalities  needed  for  the  RAP  application.  One  of  the  purposes  of  this  study 
was  to  answer  question  2.  The  following  are  the  most  important  software  properties 
for  which  the  selection  of  a  simulation  tool  was  performed.  The  simulation  tool 
selected  should  provide  as  many  as  possible  of  the  15  RAP  functionalities  listed 
earlier.  And  as  the  new-generation  RAP  necessitates  the  development  of  several  new 
functionalities,  it  would  be  preferable  to  get  open-source  code  for  the  simulation  tool 
selected.  Eventually,  the  RAP  application  will  probably  become  a  real-time 
application.  It  is  therefore  important  that  the  simulation  tool  selected  offer  excellent 
performance  and  robustness.  Because  the  scenario  selected  by  DRDC  involves  many 
simulation  entities,  the  tool  selected  should  not  be  limited  in  the  number  of  simulation 
entities  it  can  process. 
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4.  Conclusion 


To  develop  and  demonstrate  the  concepts  of  RAP  compilation  and  exploitation,  a 
scenario  able  to  support  a  type  of  operation  that  provides  events  leading  to  the 
compilation  and  exploitation  of  a  RAP  was  needed.  Six  military  scenarios  were 
analyzed. 

•  Scenario  1 :  CF  Security  Support  to  the  Winter  Olympics  2010; 

•  Scenario  2:  Atlantic  Littoral  ISR  Experiment  (ALIX); 

•  Scenario  3:  Force  Planning  Scenario  #4:  Surveillance/Control  of  Canadian 
Territory  and  Approaches; 

•  Scenario  4:  Force  Planning  Scenario  10:  Defence  of  North  America; 

•  Scenario  5:  Joint  Warrior  Interoperability  Demonstration  (JWID); 

•  Scenario  6:  Exercise  Final  Lance:  Atlantis. 

These  five  aspects  were  considered. 

•  Scenario  details  and  richness  of  information; 

•  Realism  from  a  conduct  of  operations  (tactical)  point  of  view; 

•  Possible  friendly  or  enemy  COAs; 

•  Utility  for  the  compilation  and  exploitation  of  the  RAP;  and 

•  Level  of  detail  available  and  facility  of  developing  vignettes. 

The  North  Atlantis  scenario  was  identified  as  the  one  offering  the  best  basis  for 
developing  a  vignette  which  would  be  of  interest  for  the  compilation  and  exploitation 
of  a  RAP.  Once  selected,  a  vignette  appropriate  for  RAP  compilation/exploitation  was 
developed.  The  vignette  needed  to  be  at  the  operational-tactical  level,  distributed,  with 
rich  threat  attributes,  a  dynamic  environment,  resource/asset  multiplicity  and  diversity. 
It  was  determined  that  a  vignette  of  a  CSAR  operation  would  be  appropriate. 
Accordingly,  the  vignette  was  developed  with  a  good  level  of  detail  and  including 
three  realistic  unforecasted  events: 

•  Inability  to  locate  enemy  ground  positions  due  to  cloud  and  terrain; 

•  Enemy  attack  helicopters  appear  in  the  CSAR  area; 

•  Enemy  SAM  system  in  ABR  rear  area  detects  the  CF-18  BAI  mission. 
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Once  the  vignette  was  developed,  four  simultation  tools  were  evaluated  considering 
purely  software  engineering  criteria  and  the  application  requirements  in  terms  of  RAP 
functionalities  needed  for  CSAR  simulations.  Although  the  commercial  tools  (SADM 
and  Integrated  Anti-Ship  Missile  Defence  Analysis  and  Simulation  software)  seemed 
to  be  more  refined,  the  analysis  showed  that  none  of  the  tools  emerged  as  dominant, 
i.e.,  none  outperformed  the  others  on  all  counts. 

•  SADM  is  not  open-source  and  simulates  only  a  limited  number  of  entities.  But  it 
can  fulfill  the  greatest  number  of  RAP  functionalities  and  takes  topography  into 
account,  a  feature  that  we  consider  essential.  Therefore,  it  is  recommended  that 
the  company  be  approached  to  see  ifSADM’s  limitations  can  be  addressed  (e.g., 
source  code  access  and  limited  number  of  simulation  entities). 

•  TTI  is  an  open-source  product  with  no  limitation  on  the  number  of  simulation 
entities.  But  its  source  code  is  interpreted,  and  that  may  seriously  hinder 
performance.  IfDRDC plans  to  implement  a  real-time  RAP  application,  it  is 
recommended  that  the  performance  of  TTI  be  analyzed  before  it  is  selected. 

•  CASE-ATTI  is  open-source  but  fulfills  fewer  RAP  functionalities  than  either  TTI 
or  SADM.  Still,  CASE-ATTI  offers  the  best  track  management  model.  This  model 
should  be  included  in  the  new-generation  RAP.  In  doing  this,  the  following 
actions  are  recommended:  a)  isolate  the  track  management  model  from  the  CASE- 
ATTI  interface,  and.  b)  improve  the  robustness  of  this  model  by  introducing  a 
software  verification  and  validation  plan  and  executing  the  tests  documented  in 
the  plan. 

•  KARMA  is  open-source,  but  like  CASE-ATT,  it  fulfills  fewer  RAP  functionalities 
than  either  TTI  or  SADM.  Still,  KARMA  supplies  different  simulation  entities 
such  as  logic  fuse,  which  are  not  present  in  the  other  simulation  tools.  These 
simulation  entities  should  be  included  in  the  new-generation  RAP.  In  including 
these  entities,  the  following  actions  are  recommended:  a)  isolate  these  simulation 
entities  from  the  KARMA  interface,  and  b)  improve  the  robustness  of  these 
simulation  entities  by  introducing  a  software  verification  and  validation  plan  and 
performing  the  tests  documented  in  the  plan.  Furthermore,  KARMA  contains  an 
excellent  documented  development  process  and  a  software  architecture  that 
facilitates  the  integration  of  different  models.  It  is  recommended  that  this  process 
be  adopted  to  develop  the  new-generation  RAP.  Also,  the  RAP  architecture  could 
be  based  on  the  same  architecture. 

All  things  considered,  SADM  would  be  one  of  the  best  tools  if  topography  were  not  an 
important  factor  for  simulating  DRDC  scenarios.  Owing  to  this  factor,  TTI  is  a  good 
option.  If  DRDC  plans  to  develop  a  real-time  RAP  application,  it  would  be  imprudent 
to  choose  TTI  before  thoroughly  analyzing  its  performance.  If  that  analysis  is  not 
performed,  the  only  choices  would  be  KARMA  and  CASEATTI.  As  previously 
mentioned,  KARMA  is  an  attractive  choice  because  the  development  process  is 
documented  and  the  architecture  allows  different  models  to  be  integrated.  On  the 
other  hand,  CASE  ATTI  has  the  best  track  management  model  and  an  acceptable 
developer  guide.  To  take  full  advantage  of  the  strengths  of  these  two  teams,  it  is 
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suggested  that  one  member  of  each  team  participate  in  the  architectural  phase  of  RAP 
development.  The  RAP  architects  could  draw  inspiration  from  the  integrative  aspect 
of  the  KARMA  architecture. 

A  promising  avenue  for  the  development  of  RAP  simulation  and  analysis  tools  would 
integrate  G1S  tools  for  analyzing  terrain  features  and  integration  of  typical  layers  of 
information  such  as  bodies  of  water,  elevation,  obstacles,  roads  and  airfields  take  can 
be  found  in  the  North  Atlantis  vignette  database.  It  is  clear  that  promising  GIS 
solutions  for  the  rapid  development  and  testing  of  concepts  would  use  either  a  COTS 
GIS  environment  such  as  that  marketed  by  ESRI  or  a  GIS  library  allowing  the 
development  of  tailored  display  and  analysis  tools.  Consistent  with  the  underpinnings 
of  the  KARMA  architecture,  it  was  concluded  that  instead  of  trying  to  develop  RAP 
extensions  starting  with  the  fundamentals  of  programs  like  TTI,  SADM  or 
CASEATTI,  it  would  be  easier  and  more  efficient  to  extract  the  minimum  required 
functionalities  such  as  basic  sensor  shells  and  detection,  tracking  and  identification 
algorithms  from  these  programs. 
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List  of 

symbols/abbreviations/acronyms/initialisms 


Acronym 

Description 

AAA 

Anti-Aircraft  Artillery 

AAM 

Air-to-Air  Missile 

AAT 

ATO/ACO  Tool 

ABCCC 

Airborne  Command,  Control  and  Communications 

ABR 

Airborne  Regiment 

ACC 

Air  Component  Commander 

ACO 

Airspace  Control  Order 

AD 

Airspace  Deconfliction,  Air  Defence 

ADRG 

Arc  Digitized  Raster  Graphics 

ADSI 

Air  Defense  System  Integrator 

AFATDS 

Advanced  Field  Artillery  Tactical  Data  System 

AODB 

Air  Operations  Database 

AOI 

Area  of  Interest 

AOO 

Area  Of  Operation 

API 

Application  Programming  Interface 

ASCM 

Anti-Ship  Cruise  Missile 

ATO 

Air  Tasking  Order 

ATOX 

ATO  Exchange 

AUTODIN 

Automatic  Digital  Network 

AWACS 

Airborne  Warning  and  Control  System 
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BAI 

Battlefield  Air  Interdiction 

C2/IE 

Command  and  Control  and  Information  Exchange 

C4I 

Command,  Control,  Communications,  Computers  and  Intelligence 

CADRG 

Compressed  Arc  Digitized  Raster  Graphics 

CADS 

Canadian  Air  Defence  Sector 

CAOC 

Combined  Air  Operations  Centre 

CAP 

Combat  Air  Patrol 

CAS 

Close  Air  Support 

CBT 

Computer-based  Training 

CFC 

Canadian  Forces  Command 

CFCSC 

Canadian  Forces  Command  and  Staff  College 

CFNA 

Canadian  Forces  Northern  Area 

CFOPP 

Canadian  Forces  Operational  Planning  Process 

CIWS 

Close-In  Weapon  System 

COA 

C  ourse  of  Action 

COMAO 

Combined  Air  Operation 

CONOPS 

Concept  of  Operations 

COP 

Common  Operational  Picture 

CSAR 

Combat  Search  And  Rescue 

CST 

Common  Operating  Picture  (COP)  Synchronization  Tool 

CTP 

Common  Tactical  Picture 

DBMS 

Database  Management  System 

DII-COE 

Defence  Infrastructure  Information-Common  Operating  Environment. 

DISA 

Defense  Information  Systems  Agency 
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DMS 

Degrees/Minutes/Seconds 

DND 

Department  of  National  Defence  (Canada) 

DoD 

Department  of  Defense  (USA) 

DSS 

Decision  Support  System 

DTED 

Digital  Terrain  Elevation  Data 

ECR 

Electronic  Countermeasures  and  Reconnaissance 

ECOA 

Enemy  COA 

ELINT 

Electronic  Intelligence 

ELT 

Emergency  Locator  Transmitter 

EM 

Execution  Management 

EMC 

Execution  Management  Control 

EMR 

Execution  Management  Replanning 

ESM 

Electronic  Support  Measures 

FrOB 

Friendly  Order  of  Battle 

GCCS 

Global  Command  and  Control  System 

GIS 

Geographical  Information  System 

GMIDB 

General  Military  Intelligence  Database 

GOTS 

Government  Off-the-Shelf. 

GUI 

Graphical  User  Interface. 

13 

Integrated  Intelligence  and  Imagery 

IADS 

Integrated  Air  Defense  System 

IBIS 

Integrated  Battlespace  Intelligence  Server 

IDM 

Intelligence  Data  Management 

IFF 

Identification  Friend  or  Foe 
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IR 

Infrared 

IRIS 

USMTF  message  processing  application  that  performs  message  parsing 
validation,  reformatting,  and  dissemination  functions 

IRST 

Infrared  Search  and  Track 

J2RE 

Java  2  Runtime  Environment 

JANAP 

Joint  Army,  Navy,  Air  Force  Publication 

JDP 

Joint  Defensive  Planner 

JFC 

Joint  Force  Commander 

JMTK 

Joint  Mapping  Toolkit 

JPT 

JFACC  Planning  Tool 

L1DF 

Fevel  One  Data  Fusion 

Fat/Fong 

Fatitude/Fongitude 

FPD 

Focation  Probability  Distribution 

MAOP 

Master  Air  Operations  Planner 

MCC 

Maritime  Component  Commander 

MGRS 

Military  Grid  Reference  System 

MIDB 

Modernized  Intelligence  Database 

MTC 

Multi-TADIF  Capability 

MTF 

Message  Text  Format 

NATO 

North  Atlantic  Treaty  Organization 

NIMA 

National  Imagery  and  Mapping  Agency 

NRT 

Near-Real  Time 

OGD 

Other  Government  Departments 

ORBAT 

Order  of  Battle 
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OTH-T  Gold 

Over-The-Horizon  Targeting  GOLD 

PC 

Package  Commander 

PM 

Prime  Minister 

PDF 

Portable  Document  Format  (Adobe) 

PMTLS 

Process  Management  Tools 

RAF 

(UK)  Royal  Air  Force 

RAP 

Recognized  Air  Picture 

RBC 

Remote  Briefing  Capability 

RCS 

Radar  Cross  Section 

RF 

Radio  Frequency 

SA 

System  Administrator 

SAA 

Situation  Awareness  and  Assessment 

SAAAC 

SAA  Augmented  Communications 

SAAFD 

SAA  Friendly  Order  of  Battle  Display 

SAAHLP 

SAA  On-Line  Help 

SAATD 

SAA  Terrain  Delimitation 

SAM 

Surface-to-Air  Missile 

SAR 

Search  And  Rescue 

SATDCD 

SAATD  Classified  Data 

SEAD 

Suppression  of  Enemy  Air  Defenses 

SLAM 

Simulation  Language  for  Alternative  Modelling 

SUM 

Software  User’s  Manual 

TACELINT 

Tactical  Electronic  Intelligence 

TACREP 

Tactical  Report 
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TADIL 

Tactical  Digital  Information  Link 

TAP 

Theater  Air  Planning 

TBMCS 

Theater  Battle  Management  Core  Systems 

TBMWD 

Theater  Ballistic  Missile  Warning  and  Display 

Tdbm 

Track  Database  Manager 

TEL 

T  ransporter-erector-  launchers 

TESS 

Tactical  Engagement  Simulation  Suite 

TEWA 

Threat  Evaluation  and  Weapon  Assignment 

TOI 

Tracks  of  Interest 

TOT 

Time  on  Target 

UAV 

Unmanned  Aerial  Vehicle 

UB 

Unified  Build 

UM 

User  Manual 

USMTF 

United  States  Message  Text  Format 

UTM 

Universal  Transverse  Mercator 

WAN 

Wide  Area  Network 

wcs 

Weapon  Control  System 

WebAD 

Web  Airspace  Deconfliction  system 

WVS 

World  Vector  Shoreline 

wx 

Weather  Briefing 
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